Community
Participate
Working Groups
I'm sitting at this logged exception, trying to figure out what CDT is trying to tell me: org.eclipse.core.runtime.CoreException: Invalid context at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:112) at com.verigy.itee.utm.debugger.core.TMDebuggerDelegate.launch(TMDebuggerDelegate.java:299) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:862) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:720) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1020) at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1234) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) I grepped for "Invalid context", unsurprisingly the string is all over the place. Now I'm setting a conditional breakpoint at org.eclipse.cdt.dsf.concurrent.RequestMonitor.setStatus(IStatus) to figure out, what exactly the invalid context is. And if the above gets logged by a test that fails 1 time in 1000 executions? What do I do then? A logged error without a stack trace is mostly useless, it would be great if this can be improved.
For the case above this seems to be coming from org.eclipse.cdt.dsf.mi.service.MIBreakpointsManager.startTrackingBreakpoints(IBreakpointsTargetDMContext, RequestMonitor): // Validate the execution context if (dmc == null) { rm.setStatus(new Status(IStatus.ERROR, GdbPlugin.PLUGIN_ID, REQUEST_FAILED, INVALID_CONTEXT, null)); rm.done(); return; } Personally I would suggest adding an exception to the status. Considering that the debug launch fails to even start when this occurs, the expense of querying the current stack trace should not matter. I'm guessing this is a common pattern in the DSF code though (seeing how all results are retrieved). So likely there are many more places like this. Also no idea how AERI reports for this type of (bare-bones) error log look like.
I have had this sort of problem too. See Bug 507855 for another class of exceptions being lost by CDT. I started working on a patch many years ago, but it was never finished/submitted.
Another one occurred during one of our tests: !ENTRY org.eclipse.cdt.dsf 4 10005 2020-04-18 19:28:23.253 !MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.concurrent.RequestMonitor@34253373): Status OK: unknown code=0 OK null' resulted in a rejected execution exception. I expect the code for this is in RequestMonitor.handleRejectedExecutionException(). The other occurrences of the same error message add exceptions to the error status, but the above status has no exception (and so absolutely no idea what caused it).
