[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Why doesn't DSF-GDB timeout when it submits query?
Thanks for the quick response, Marc!

I will pay attention to Bug 365601 and contribute as I can – may be testing effort as the bug is not easy to reproduce.

I agree with you that for future usage of DSF Query we should use timeout as possible as we can, especially when we run in the UI thread we can't predict what can go wrong in the background.

Unfortunately it's too late to change the current implementation because there are too many places using the "get()" method now. We can fix them when problems arise.

Thanks,
Andy

From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Tuesday, 17 July, 2012 1:32 PM
To: "'CDT General developers list.'" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Why doesn't DSF-GDB timeout when it submits query?

Hi Andy,
 
The deadlock below is being worked on as we speak.  Please see:
 
As for using the timeout in query, I'm personally not aware of any reason why
we shouldn't use it.  Choosing the right timeout should be done carefully though.
That approach wasn't used when we started and that kind of became the pattern.
We can start introducing such timeouts in different parts as needed.
If you feel that would be helpful, you can file a bug.
 
Thanks
 
Marc

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
Sent: Tuesday, July 17, 2012 1:23 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Why doesn't DSF-GDB timeout when it submits query?

Some users report the debug session hangs the IDE. The stack trace is copied below. At that stage, "gdb" hangs for some unknown reason (that will be looked at separately), but the stack trace shows DSF GDB is waiting for gdb infinitely and that hangs the main UI thread.

The org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConnect() method sends the connect query using the org.eclipse.cdt.dsf.concurrent.Query.get() method. The "get()" method is blocked with no timeout. There is another "get(timeout, timeoutUnit)" method but it is not used.

In fact, I see almost all DSF-GDB classes use the "get()" method, e.g. GdbLaunchDelegate. In the case when gdb hangs, those methods will block. Is there any reason we don't use the "get(timeout, timoutUnit)" method?

Thanks,
Andy

"main" prio=6 tid=0x02269800 nid=0x1514 in Object.wait() [0x0018e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x1ea4a7f0> (a
org.eclipse.cdt.dsf.concurrent.Query$QueryR
m)
        at java.lang.Object.wait(Object.java:485)
        at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:105)
        - locked <0x1ea4a7f0> (a org.eclipse.cdt.dsf.concurrent.Query$QueryRm)
        at
org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConn
ect(GdbConnectCommand.java:100)
        at
org.eclipse.cdt.dsf.gdb.internal.ui.actions.ConnectActionDelegate.upd
ateEnablement(ConnectActionDelegate.java:65)
        at
org.eclipse.cdt.dsf.gdb.internal.ui.actions.ConnectActionDelegate.deb
ugContextChanged(ConnectActionDelegate.java:52)
        at
org.eclipse.debug.internal.ui.contexts.DebugWindowContextService$1.ru
n(DebugWindowContextService.java:194)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at
org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.noti
fy(DebugWindowContextService.java:192)
        at
org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.noti
fy(DebugWindowContextService.java:181)
        at
org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.debu
gContextChanged(DebugWindowContextService.java:390)
        at
org.eclipse.debug.ui.contexts.AbstractDebugContextProvider$1.run(Abst
ractDebugContextProvider.java:79)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at
org.eclipse.debug.ui.contexts.AbstractDebugContextProvider.fire(Abstr
actDebugContextProvider.java:77)
        at
org.eclipse.debug.internal.ui.views.launch.LaunchView$ContextProvider
Proxy.debugContextChanged(LaunchView.java:477)
        at
org.eclipse.debug.ui.contexts.AbstractDebugContextProvider$1.run(Abst
ractDebugContextProvider.java:79)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at
org.eclipse.debug.ui.contexts.AbstractDebugContextProvider.fire(Abstr
actDebugContextProvider.java:77)
        at
org.eclipse.debug.internal.ui.views.launch.LaunchView$TreeViewerConte
xtProvider.possibleChange(LaunchView.java:368)
        at
org.eclipse.debug.internal.ui.views.launch.LaunchView$TreeViewerConte
xtProvider$Visitor.visit(LaunchView.java:291)
        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$TreeViewerConte
xtProvider.modelChanged(LaunchView.java:396)
        at
org.eclipse.debug.internal.ui.viewers.model.ModelContentProvider.doMo
delChanged(ModelContentProvider.java:1390)
        at
org.eclipse.debug.internal.ui.viewers.model.ModelContentProvider.mode
lChanged(ModelContentProvider.java:1364)
        at
org.eclipse.cdt.dsf.ui.viewmodel.DefaultVMModelProxyStrategy$1.run(De
faultVMModelProxyStrategy.java:144)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at
org.eclipse.cdt.dsf.ui.viewmodel.DefaultVMModelProxyStrategy.fireMode
lChanged(DefaultVMModelProxyStrategy.java:148)
        at
org.eclipse.cdt.dsf.ui.viewmodel.update.AbstractCachingVMProvider$6.h
andleSuccess(AbstractCachingVMProvider.java:881)
        at
org.eclipse.cdt.dsf.concurrent.RequestMonitor.handleCompleted(Request
Monitor.java:353)
        at
org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.ja
va:298)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
        at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.ja
va:135)
        - locked <0x1ea4aa10> (a org.eclipse.swt.widgets.RunnableLock)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
        at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
        at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
        at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
        at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.ja
va:332)
        at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav
a:668)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
        at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEAppli
cation.java:123)
        at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandl
e.java:196)
        at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runAppli
cation(EclipseAppLauncher.java:110)
        at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ec
lipseAppLauncher.java:79)
        at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:344)
        at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

"VM Thread" prio=10 tid=0x0212f800 nid=0x1e3c runnable

"VM Periodic Task Thread" prio=10 tid=0x4cda8800 nid=0x6c8 waiting on condition