Community
Participate
Working Groups
xdc.tools.Server contains a Java SecurityManager that prevents .xs scripts from shutting down all of CCS via java.lang.System.exit(). In CCSv5, the Eclipse Debug Server Framework (DSF) creates threads that accidentally activate the SecurityManager, and refuse permission for some operations during CCS shutdown. SecurityManager is being removed in XDCtools 3.21, should be removed in 3.20 stream also.
My guess on the mechanism is that the ROV server is making a callback into CCS to fetch data, and this is causing a new part of DSF to spin up. Internally it's creating a thread pool, but doing that work on the ROV server thread. The ROV server thread has a particular thread group that the security manager sets to identify its clients, and the new threads on the new thread pool are inheriting this thread group because they're not explicitly setting their own. Top of exception stack trace: Thread [com.ti.ccstudio.debug.debugModel - 0] (Suspended (exception AccessControlException)) AccessControlContext.checkPermission(Permission) line: not available AccessController.checkPermission(Permission) line: not available DefaultDsfExecutor(ThreadPoolExecutor).shutdown() line: not available DefaultDsfExecutor(ScheduledThreadPoolExecutor).shutdown() line: not available DefaultDsfExecutor.shutdown() line: 490
Fixed in xdc-v54
Change state to RESOLVED
Reproduced problem with CCS5.0.0.00025 build and XDCtools 3.20.06.81 using the following steps: 1. Create BIOS example project for DM6437 2. Build program and load on target 3. Launch ROV 4. Shutdown IDE. The "eclipse.exe" process is seen in the task manager. Note that this problem is only observed when debugging on a target board. Couldn't reproduce the problem when a simulator is used. Updated to XDCtools 3.20.07-84-eng build. Followed steps 1-3. Shutdown the IDE. This time around no "eclipse.exe" process is observed in the task manager.
Verified in XDCtools 3.20.07.84-eng.
Shipped in XDCtools 3.21
