Community
Participate
Working Groups
Created attachment 259442 [details] Dsf Session trace What I am seeing is that Eclipse will deadlock when you exit an application you are debugging in CDT with GDB. It does not always do this, launching eclipse in the Debug perspective seems to help. The first deadlock occurs with the main thread stuck in GdbSteppingModeTarget supportsInstructionStepping even after "mitigating" that issue, I see the next two at ResumeAtLine canResumeAtLine ResumeAtLine resumeAtLine Forcing the Query Class to Timeout always at least would prevent a total deadlock, but it would hang 4-5 times in the main thread until GDB would terminate. I turned on some of the Dsf Session Trace and attached it. Please let me know of any information you need.
I have looked into this further, and found one of our plugins adding UI a dependency that causes a deadlock between the main thread and the Dsf executor. I changed how my plugin works and I no longer have a deadlock, but here are the details you can read about. I contained my changes outside of CDT, but you can decide if my Use Case was valid or not, but I am happy now. So the key to my issue, was I have a class creates a ILaunchConfigurationListener One of the things it would do was on settings changes, request a UI update from the UI thread. What seems to happen, is that during the end of GDB debugging, I would get to DsfMemoryBlockRetrieval.saveMemoryBlocks, which changes settings and would activate the ILaunchConfigurationListener . This ILaunchConfigurationListener would then kick off a syncExec( refresh ) request. This caused the org.eclipse.cdt.dsf.gdb-0 executor to wait for the UI Updated. As Shown org.eclipse.cdt.dsf.gdb-0 -UISynchronizer().syncExec() id=227 -ILaunchConfigurationListener (MY PLUGIN) -GdbMemoryBlockReterival().saveMemoryBlocks -DsfSession ..... So, the executor is now waiting. Then what would happen, is in the main thread (is this the GUI thread?) it would call out to GdbSteppingModeTarget.supportsInstructionStepping and this function waits on the dsf executor. Here is the call chain main -waiting for: Query$QueryRm id=164 -GdbSteppingModeTarget().supportsInstructionStepping -SimpleDisplayExecutor -UISynchronizer().runAsyncMessage id=227 If I look at the supportsInstructionStepping DefaultDsfExecutor it shows executor.queue[0] -> GdbSteppingModeTarget.Query id=164 I moved my ILaunchConfigurationListener->UISynchronizer().syncExec() call into its own thread to prevent this deadlock so the GdbMemoryBlockReterival().saveMemoryBlocks could finish, let the executor finish, then the main thread would finish, then once the UI update finished, my new thread would finish.
