Hi all,
I'm trying to use DSF instead of the old CDI debugger, so far I've managed to trigger debug executions with a custom launch. But I'm having trouble with suspending the debug session from product/test code.
Here is roughly the code at which I've arrived (note that its part of a test):
IAdaptable context = DebugUITools.getDebugContext();
IDMContext dmc = context.getAdapter(IDMContext.class);
DsfSession mi = DsfSession.getSession(dmc.getSessionId());
IExecutionDMContext executionContext = DMContexts.getAncestorOfType(dmc, IExecutionDMContext.class);
DsfServicesTracker tracker = new DsfServicesTracker(Activator.getDefault().getBundle().getBundleContext(), mi.getId());
IRunControl runControl = tracker.getService(IRunControl.class);
// wait up to 30 seconds for IRunControl.canSuspend() to return true
ImmediateRequestMonitor suspendRequestMonitor = new ImmediateRequestMonitor(null);
runControl.suspend(executionContext, suspendRequestMonitor);
assertTrue("Failed to suspend CDT DSF debug launch", suspendRequestMonitor.isSuccess());
// wait up to 30 seconds for IRunControl.isSuspended() to return true
// the wait for suspend times out
I'm seeing this in the error log:
!MESSAGE Request for monitor: 'RequestMonitor (com.verigy.itee.utm.test.debug.TestUtmDebuggerProxy$1@2fddae92): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Suspend operation timeout. null' resulted in an error.
Unfortunately I don't know how to continue debugging the DSF code (to find out what the problem is), I see e.g.
"55-exec-interrupt --thread 1"
is written to some output stream in AbstractMIControl.TxThread.run(). The respective error stream doesn't contain anything, no lines are read in: AbstractMIControl.ErrorThread. I found bug 509812 (which was fixed in 2017), but nothing else. I also tried increasing the timeout in GDBRunControl_7_0_NS.MonitorSuspendJob.TIMEOUT_DEFAULT_VALUE to 30 seconds, still the same results.
CDT is version 9.6.
GDB version should be: GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
I'm using IGDBLaunchConfigurationConstants.ATTR_DEBUGGER_NON_STOP set to true.
The debug execution context is at:
(gdb[0].proc[52864].threadGroup[i1],gdb[0].proc[52864].OSthread[1]).thread[1]
I've added some outputs for writing and reading in AbstractMIControl, here is what I see (it seems fine to me):
[Mon Mar 09 14:32:10 CET 2020] Read: (gdb)
[Mon Mar 09 14:32:10 CET 2020] Wrote: 66-exec-interrupt --thread 1
[Mon Mar 09 14:32:10 CET 2020] Read: 66^done
[Mon Mar 09 14:32:10 CET 2020] Read: (gdb)
!ENTRY org.eclipse.cdt.dsf 4 10005 2020-03-09 14:32:20.502
!MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.concurrent.ImmediateRequestMonitor@331190c1): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Suspend operation timeout. null' resulted in an error.
There is only 1 "exec-interrupt" command in the output.
Note that I have no experience with GDB itself, I'm not a C/C++ developer.
Best regards and thanks,
Simeon