Community
Participate
Working Groups
Build Identifier: I20110613-1736 When launching a debug configuration from a workspace (I will attach the workspace) the UI becomes unresponsive to the point of not repainting. I think the problem is that it gets stuck at the wait() in the call to canConnectQuery.get() in canConnect() in GDBConnectCommand. I suspect that for some reason the RM is never completing and so the call to notifyAll never happens in the QueryRM. I should mention that this might be due to a slightly incorrect (but understandably so) use of an Eclipse path variable in the debug configuration environment as changing that to use absolute paths seems to make the problem go away. Even if that is the cause then I'm not sure that locking the GUI so it needs to be killed is the correct reaction ;-) Reproducible: Sometimes Steps to Reproduce: 1. Unzip attached workspace 2. Open workspace in eclipse 3. Run the LibraryUsage Debug configuration 4. If it runs to completion then go to 3. It usually crashes within 3 or 4 tries and I don't thing I've ever seen it get past 15 starts before failing.
Created attachment 207920 [details] The attached workspace hangs on my system This is the test workspace I use to demonstrate the bug on my system. It contains 2 projects, LibraryCreationTest: This creates a very simple .so LibraryUsage: This has a very simple main and uses the .so On my system the debug configuration LibraryUsage Debug causes Eclipse to hang about 1 time in 3. This is a minimal version of a more complicated workspace that displays the same problem.
Marc, I have noticed this too. It seems to be a deadlock but it is difficult to reproduce. I also noticed that "Connect" action is updated much often than other debug actions. Why it is not implemented as a "DebugCommandAction"?
(In reply to comment #2) > Marc, I have noticed this too. It seems to be a deadlock but it is difficult to > reproduce. > I also noticed that "Connect" action is updated much often than other debug > actions. Why it is not implemented as a "DebugCommandAction"? The Connect command has been causing some problems on and off for a while now. When I wrote it the "DebugCommandAction" was not available. If we can migrate to it now, it would be great.
(In reply to comment #2) > Marc, I have noticed this too. It seems to be a deadlock but it is difficult to > reproduce. Mikhail, does this mean that the test workspace doesn't lock up on your system? Is there anything else that I can supply to help (such as a stack trace from a locked Eclipse). Also, neither jConsole or Eclipse detects a deadlock.
(In reply to comment #4) > Mikhail, does this mean that the test workspace doesn't lock up on your system? > Is there anything else that I can supply to help (such as a stack trace from a > locked Eclipse). Also, neither jConsole or Eclipse detects a deadlock. Phil, I haven't tried to reproduce it with your workspace yet - just didn't have time. I have seen the UI frozen in "canConnect()" several times but never had a chance to investigate it seriously. You may be right, it could be just a request monitor not a deadlock. I can try to your workspace but I think it's a timing issue. The problem would be fixed if "Connect" was implemented as "DebugCommadAction". In this case all tests would be done in none UI threads.
Happened twice today since I upgraded to Juno. Never see it before. UI (main) thread is blocked forever and kill <pid> is the only solution. "main" prio=10 tid=0x00007fc3b8006800 nid=0x4221 in Object.wait() [0x00007fc3bfb2b000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:106) - locked <0x00000000edf3b0c0> (a org.eclipse.cdt.dsf.concurrent.Query$QueryRm) at org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConnect(GdbConnectCommand.java:105) at org.eclipse.cdt.dsf.gdb.internal.ui.actions.ConnectActionDelegate.updateEnablement(ConnectActionDelegate.java:66) at org.eclipse.cdt.dsf.gdb.internal.ui.actions.ConnectActionDelegate.debugContextChanged(ConnectActionDelegate.java:53) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService$1.run(DebugWindowContextService.java:212) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.notify(DebugWindowContextService.java:210) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.notify(DebugWindowContextService.java:193) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.debugContextChanged(DebugWindowContextService.java:408) at org.eclipse.debug.ui.contexts.AbstractDebugContextProvider$1.run(AbstractDebugContextProvider.java:79) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.ui.contexts.AbstractDebugContextProvider.fire(AbstractDebugContextProvider.java:77) at org.eclipse.debug.internal.ui.views.launch.LaunchView$ContextProviderProxy.debugContextChanged(LaunchView.java:506) at org.eclipse.debug.ui.contexts.AbstractDebugContextProvider$1.run(AbstractDebugContextProvider.java:79) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.ui.contexts.AbstractDebugContextProvider.fire(AbstractDebugContextProvider.java:77) at org.eclipse.debug.internal.ui.views.launch.LaunchView$TreeViewerContextProvider.possibleChange(LaunchView.java:397) at org.eclipse.debug.internal.ui.views.launch.LaunchView$TreeViewerContextProvider$Visitor.visit(LaunchView.java:320) at org.eclipse.cdt.dsf.ui.viewmodel.VMDelta.doAccept(VMDelta.java:359) at org.eclipse.cdt.dsf.ui.viewmodel.VMDelta.doAccept(VMDelta.java:362) at org.eclipse.cdt.dsf.ui.viewmodel.VMDelta.accept(VMDelta.java:354) at org.eclipse.debug.internal.ui.views.launch.LaunchView$TreeViewerContextProvider.modelChanged(LaunchView.java:425) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:415) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.modelChanged(TreeModelContentProvider.java:384) at org.eclipse.cdt.dsf.ui.viewmodel.DefaultVMModelProxyStrategy$1.run(DefaultVMModelProxyStrategy.java:154) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.cdt.dsf.ui.viewmodel.DefaultVMModelProxyStrategy.fireModelChanged(DefaultVMModelProxyStrategy.java:158) at org.eclipse.cdt.dsf.ui.viewmodel.update.AbstractCachingVMProvider$6.handleSuccess(AbstractCachingVMProvider.java:900) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.handleCompleted(RequestMonitor.java:376) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:303) at org.eclipse.cdt.dsf.ui.concurrent.SimpleDisplayExecutor.runInSwtThread(SimpleDisplayExecutor.java:117) at org.eclipse.cdt.dsf.ui.concurrent.SimpleDisplayExecutor$1.run(SimpleDisplayExecutor.java:80) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) - locked <0x00000000eadc66d8> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3529) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3182) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
Created attachment 218756 [details] Stack trace when main thread blocked Happened a third time... Never see this before Juno (4.2). Indigo (3.7) worked pretty good with the same workspace. This is the full output of jstack.
How do you get it to happen? Is it when you terminate the debug session that you see the problem? A fix was pushed in Bug 382496 but it missed the Juno release.
(In reply to comment #8) > How do you get it to happen? Is it when you terminate the debug session that > you see the problem? > > A fix was pushed in Bug 382496 but it missed the Juno release. No, it happens when I press F11 to start the application in debug mode. It seems not to happen on the first run but afterwards. I can't reproduce it every time but hit it several times today.
(In reply to comment #8) > How do you get it to happen? Is it when you terminate the debug session that > you see the problem? > > A fix was pushed in Bug 382496 but it missed the Juno release. Marc, this seems to be a different issue than https://bugs.eclipse.org/bugs/show_bug.cgi?id=382496. I have seen this in the earlier releases.
(In reply to comment #7) > Created attachment 218756 [details] > Stack trace when main thread blocked Thanks for this. So it is a deadlock (see below). Time to try to convert GdbConnectCommand to DebugCommandAction. Deadlock: -------- The UI thread is waiting on the DSF executor in GdbConnectCommand: "main" prio=10 tid=0x00007f015c006800 nid=0x3370 in Object.wait() [0x00007f0161ce9000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000ef6b37f8> (a org.eclipse.cdt.dsf.concurrent.Query$QueryRm) at java.lang.Object.wait(Object.java:502) at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:106) - locked <0x00000000ef6b37f8> (a org.eclipse.cdt.dsf.concurrent.Query$QueryRm) at org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConnect(GdbConnectCommand.java:105) while DSF executor is waiting to use the UI thread through a call to the debug platform: "org.eclipse.cdt.dsf.gdb - 3" prio=10 tid=0x00007f00d4029000 nid=0x5c9b in Object.wait() [0x00007f0148706000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000f01da1d8> (a org.eclipse.swt.widgets.RunnableLock) at java.lang.Object.wait(Object.java:502) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:187) - locked <0x00000000f01da1d8> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4291) at org.eclipse.debug.internal.ui.stringsubstitution.SelectedResourceManager.getSelectedResource(SelectedResourceManager.java:128) at org.eclipse.debug.internal.ui.stringsubstitution.SelectedResourceResolver.resolveValue(SelectedResourceResolver.java:32) at org.eclipse.core.internal.variables.DynamicVariable.getValue(DynamicVariable.java:55) at org.eclipse.core.internal.variables.StringSubstitutionEngine.resolve(StringSubstitutionEngine.java:270) at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:195) at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:87) at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:574) at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:350) at org.eclipse.debug.internal.core.variables.ResourceResolver.getSelectedResource(ResourceResolver.java:127) at org.eclipse.debug.internal.core.variables.ResourceResolver.resolveValue(ResourceResolver.java:47) at org.eclipse.core.internal.variables.DynamicVariable.getValue(DynamicVariable.java:55) at org.eclipse.core.internal.variables.StringSubstitutionEngine.resolve(StringSubstitutionEngine.java:270) at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:195) at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:87) at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:574) at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:350) at org.eclipse.debug.internal.core.LaunchManager.getEnvironment(LaunchManager.java:1291) at org.eclipse.cdt.dsf.gdb.service.GDBBackend.getEnvironmentVariables(GDBBackend.java:325) at org.eclipse.cdt.dsf.gdb.service.DebugNewProcessSequence.stepSetEnvironmentVariables(DebugNewProcessSequence.java:163)
Just happened again. Same/similar stacktraces. Marc, I'm looking forward to test your fix ;-) Thank you.
(In reply to comment #1) > Created attachment 207920 [details] > The attached workspace hangs on my system I can reproduce the problem with Phil's workspace. I had to change a hard-coded path in the built settings and one must be in the Debug view (so that the Connect button is visible), but after that it happens quickly. It is the same deadlock that Cyril reported.
I've quickly coded something to try out. Seems to fix the problem when I use Phil's workspace. I pushed the code to Gerrit if someone can try it out: https://git.eclipse.org/r/6816 I really didn't pay attention to the details, so it needs some cleanup, but it should be enough to try it out.
(In reply to comment #14) > I've quickly coded something to try out. Seems to fix the problem when I use > Phil's workspace. > > I pushed the code to Gerrit if someone can try it out: > https://git.eclipse.org/r/6816 > > I really didn't pay attention to the details, so it needs some cleanup, but it > should be enough to try it out. Marc, if you need a reviewer I can do it but not right now.
(In reply to comment #15) > Marc, if you need a reviewer I can do it but not right now. Thanks Mikhail. Let me clean it up before you spend time on it. I'm not sure if Cyril can test directly from Gerrit, but that would be a good indication that things are fixed.
Looking at the deadlock I think it would be better to fix the GDBBackend which waits on the UI thread. We make the assumption that the DSF thread never blocks to wait for another thread and calling LaunchManager.getEnvironment() seems to break that assumption. I.e. there are other places where we block to UI thread to call into the DSF services, like the cell editor or drag and drop handlers. Fixing the connect action is good, but I'm afraid it may not completely take care of the problem. I would suggest to deprecate IGDBBackend.getEnvironmentVariables(), and replace it with an async version. It is called only from a launch sequence as far as I can tell.
(In reply to comment #16) > I'm not sure if Cyril can test directly from Gerrit, but that would be a good > indication that things are fixed. Hi Marc, I setup a CDT workspace and got your code from Gerrit. I exported the "org.eclipse.cdt" feature ("Export..." -> "Deployable feature") and copied the results to the dropins/ folder. However, Eclipse does not seem to load it. I'm missing the good old time when you could update a bundle by just copying a newer version into plugins/... So if you have an hint how to deploy the new bundles into my current Juno install, I would greatly appreciate it. Thank you.
(In reply to comment #18) > (In reply to comment #16) > > I'm not sure if Cyril can test directly from Gerrit, but that would be a good > > indication that things are fixed. > > Hi Marc, > > I setup a CDT workspace and got your code from Gerrit. If you have the code in your eclipse, you can launch a new Eclipse that will run this new code. Create a launch from "Eclipse Application", in the main tab, choose the workspace where you had the hanging problem, and in the main tab, I use "Run a product: org.eclipse.sdk.ide". When you launch, you should see a new eclipse come up. This eclipse will have my fix running and hopefully you don't see the deadlock.
(In reply to comment #17) > I would suggest to deprecate IGDBBackend.getEnvironmentVariables(), and replace > it with an async version. It is called only from a launch sequence as far as I > can tell. Do you mean that such an async call would start a non-DSF-executor job to call DebugPlugin.getDefault().getLaunchManager().getEnvironment() which will wait for the UI but will no longer block the DSF-executor?
I've pushed patch set 2 to Gerrit. It is ready for review. JUnit tests pass as expected. One thing I wasn't able to do (which didn't work before either), is to re-enable the connect button after the user presses the 'cancel' button. Any suggestions? I'll look into Pawel's suggestion of making IGDBBackend.getEnvironmentVariables() asynchronous.
(In reply to comment #20) > Do you mean that such an async call would start a non-DSF-executor job to call > DebugPlugin.getDefault().getLaunchManager().getEnvironment() > which will wait for the UI but will no longer block the DSF-executor? Right, since the getEnvironment() call eventually synchronizes into the UI thread. A UIJob or Display.asyncExec() would seem most appropriate.
(In reply to comment #17) > Looking at the deadlock I think it would be better to fix the GDBBackend which > waits on the UI thread. We make the assumption that the DSF thread never > blocks to wait for another thread and calling LaunchManager.getEnvironment() > seems to break that assumption. I.e. there are other places where we block to > UI thread to call into the DSF services, like the cell editor or drag and drop > handlers. Fixing the connect action is good, but I'm afraid it may not > completely take care of the problem. > > I would suggest to deprecate IGDBBackend.getEnvironmentVariables(), and replace > it with an async version. It is called only from a launch sequence as far as I > can tell. I'm afraid the problem is worse than just calling LaunchManager.getEnvironment(). Looking at the stack trace, the locking call goes through: VariablesPlugin.getDefault(). getStringVariableManager().performStringSubstitution(value) This method is also called in: IGDBBackend.getGDBWorkingDirectory() IGDBBackend.getProgramArguments() GDBJtagDSFFinalLaunchSequence DebugNewProcessSequence.stepSpecifyCoreFile() and probably more, as well as other places in the debug platform which we may or may not be calling from the DSF-executor. I think the question becomes, do the places where we lock the UI thread to call the DSF-executor (cell editor, drag and drop), do they deal with the variable manager that calls into the UI and locks us up? My guess is that they probably don't. The issue we had here was that the Connect button was being refreshed during the launch, but if we don't have such a situation during the launch, I think the odds are much better not to hit this problem. Thoughts?
(In reply to comment #23) > I think the question becomes, do the places where we lock the UI thread to call > the DSF-executor (cell editor, drag and drop), do they deal with the variable > manager that calls into the UI and locks us up? I'm not sure I follow. I think the deadlock is a matter of timing. Any query from UI thread could deadlock. GDBConnect just happens to have the lucky timing in this case. If calling the variable manager is an issue, maybe we could try to avoid it if it's not really needed. E.g., could you call ILaunchConfiguration.getAttribute(ATTR_ENVIRONMENT_VARIABLES) directly?
(In reply to comment #24) > (In reply to comment #23) > > I think the question becomes, do the places where we lock the UI thread to call > > the DSF-executor (cell editor, drag and drop), do they deal with the variable > > manager that calls into the UI and locks us up? > > I'm not sure I follow. I think the deadlock is a matter of timing. Any query > from UI thread could deadlock. That is true in general. The specific situation when calling IGDBBackend can cause a problem, is during the launch only. Therefore, if the UI-locking queries don't happen during the launch, I'm under the impression it won't a problem. > If calling the variable manager is an issue, maybe we could try to avoid it if > it's not really needed. E.g., could you call > ILaunchConfiguration.getAttribute(ATTR_ENVIRONMENT_VARIABLES) directly? What would break the use of variables (e.g. $project_loc) within environment variables defined by the user. In fact the root of the problem is the variable substitution that is being done, and that is done is multiple places during the launch.
I've pushed another version to update the pom.xml files for the two plugins that changed version. I still need to code slightly different solution for the maintenance branch so that we don't change API.
(In reply to comment #21) > One thing I wasn't able to do (which didn't work before either), is to > re-enable the connect button after the user presses the 'cancel' button. Any > suggestions? I think a simple solution would be to return "true" from 'GdbConnectCommand.isRemainEnabled()'. I added the same comment to the Gerrit review.
(In reply to comment #16) > I'm not sure if Cyril can test directly from Gerrit, but that would be a good > indication that things are fixed. I finally managed to load the patched bundles (patchset 2 from Gerrit) into my current CDT 8.1 install. No deadlock so far :-) Thank you for the fix.
(In reply to comment #27) > I think a simple solution would be to return "true" from > 'GdbConnectCommand.isRemainEnabled()'. I added the same comment to the Gerrit > review. Sorry Mikhail, I missed that comment. I believe the isRemainEnabled() call is meant to decide is the button should remain enabled right after being pressed. Although it would fix the problem of not refreshing after a 'cancel, I'm worried that it would allow a user to click on the connect button more than once quickly. I tried it and double-clicked on the connect button. I didn't see two Connect dialogs. However, if I put a breakpoint in GdbConnectCommand and then do the double-click, we actually eventually get two connect dialogs. We could add some logic in GdbConnectCommand, to ignore requests when there is an on-going one, but I am hoping there is a better way to refresh the button.
(In reply to comment #28) > I finally managed to load the patched bundles (patchset 2 from Gerrit) into my > current CDT 8.1 install. No deadlock so far :-) Thank you for the fix. Awesome! Thanks for reporting back.
Created attachment 218931 [details] Possible very simple fix for the maintenance branch For the maintenance branch, would it suffice to add a timeout to the call to Query.get() in GdbConnectCommand? The canConnect() call does not require any interaction with GDB so a short timeout would probably be ok. Something like 50ms. This does fix the deadlock based on Phil's workspace. What do people think about that solution, as shown in the attached patch? Or should we still make GdbConnectCommand asynchronous, just avoiding API changes?
+1 for a simpler and quick fix in the maintenance branch. This has hit us hard because our gdb hangs on certain operations, and IDE was frozen at the canConnect() call. I just have some questions on your comment in the patch "The next attempt will fix this". How the next attempt fix this if the gdb backend hangs? What will trigger the re-connect()? And how the UI response when the canConnect() call returns false?
(In reply to comment #32) > +1 for a simpler and quick fix in the maintenance branch. > > This has hit us hard because our gdb hangs on certain operations, and IDE was > frozen at the canConnect() call. > > I just have some questions on your comment in the patch "The next attempt will > fix this". How the next attempt fix this if the gdb backend hangs? What will > trigger the re-connect()? And how the UI response when the canConnect() call > returns false? Andy, the timeout support for gdb commands is available in CDT 8.1. Does activating it help with your issues?
(In reply to comment #33) > > Andy, the timeout support for gdb commands is available in CDT 8.1. Does > activating it help with your issues? Mikhail, we are on 8.0.2, that's why Marc's patch to maintenance branch is needed.
(In reply to comment #34) > (In reply to comment #33) > > > > Andy, the timeout support for gdb commands is available in CDT 8.1. Does > > activating it help with your issues? > > Mikhail, we are on 8.0.2, that's why Marc's patch to maintenance branch is > needed. I believe Marc's maintenance patch is intended for 8.1.1.
(In reply to comment #35) > > Mikhail, we are on 8.0.2, that's why Marc's patch to maintenance branch is > > needed. > > I believe Marc's maintenance patch is intended for 8.1.1. Yes, the plan is for 8.1.1. But I could check in the query(timeout) fix on the 8.0.2 branch if you want. Mikhail or Pawel (or both :)), what do you think about the timeout solution for the maintenance branch?
+1 Not pretty, but safe.
(In reply to comment #37) > +1 > Not pretty, but safe. I agree with Pawel.
+1 to merge it to 8.0.2 branch. Thanks Marc.
(In reply to comment #32) > I just have some questions on your comment in the patch "The next attempt will > fix this". How the next attempt fix this if the gdb backend hangs? What will > trigger the re-connect()? And how the UI response when the canConnect() call > returns false? When canConnect() returns false, the connect button in the Debug view toolbar will be disabled. However, the UI calls this method quite often, so if the query timesout, the next call to canConnect() will try again and hopefully provide the correct result.
I committed the simple fix to branch 8_0: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?h=cdt_8_0&id=2507788546f39c44598ba5b97538b960cb85f804 branch 8_1: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?h=cdt_8_1&id=43fc027a9c3287ca157381d3d7423c39ab262953 The more complicated and proper fix is under review in Gerrit for master.
(In reply to comment #2) Mikhail wrote: > I also noticed that "Connect" action is updated much often than other debug > actions. Why it is not implemented as a "DebugCommandAction"? I confirmed that canConnect() is being much less now that it is a "DebugCommandAction". About 7 times less!
I committed to master the change to make the GdbConnectCommand to use DebugCommandAction. Thanks Mikhail for the review.
Fixed
*** cdt git genie on behalf of Marc Khouzam *** Bug 365601: GUI can become unresponsive when starting a debug launch [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=2507788546f39c44598ba5b97538b960cb85f804
*** cdt git genie on behalf of Marc Khouzam *** Bug 365601: GUI can become unresponsive when starting a debug launch. Solution for the maintenance branch only. Change-Id: Ice9f9e0b4700bd40b7af133def9d8396b8e20011 [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=43fc027a9c3287ca157381d3d7423c39ab262953
Practically the same problem, only in a slightly different place, still exists as Bug 546000.
