[cdt-dev] Fwd: How to suspend a DSF debug session?

[S A <simeon.danailov.andreev@xxxxxxxxx>]

Hi,

to answer my own question, I've noticed our product uses .gdbinit with the following lines:

handle SIGSTOP nostop
handle SIGSTOP noprint

When combined with IGDBLaunchConfigurationConstants.ATTR_DEBUGGER_NON_STOP set to "true", apparently the CDI/DSF debuggers are unable to suspend.

Our debugger based on DSF unfortunately suspends (all threads) on attach launch, which is not the case for the old implementation based on CDI. We are trying to use ATTR_DEBUGGER_NON_STOP to prevent this. Is there a way to not suspend all threads on attach, that does not involve using ATTR_DEBUGGER_NON_STOP (note that this is not improved by setting ATTR_DEBUGGER_STOP_AT_MAIN to "false")? We can maybe resort to a job that resumes the launch after its started, but it would be great if there is no suspend in the first place.

Best regards,

Simeon

---------- Forwarded message ---------
From: S A <simeon.danailov.andreev@xxxxxxxxx>
Date: Mon, 9 Mar 2020 at 15:36
Subject: How to suspend a DSF debug session?
To: <cdt-dev@xxxxxxxxxxx>

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