Skip to main content

[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?

"My personal preference is to have a frozen UI since it forces developers to fix it fast."

I respect that from a developer point of view, but from a user point of view he is left with a "dead" product. User does not have too many patiences he may just stop using your product. Every product can fail, but it should fail gracefully and gives user the reason so he can take appropriate action (like fixing the connection issue).


From: Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Tuesday, 17 July, 2012 2:29 PM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Why doesn't DSF-GDB timeout when it submits query?


On 07/17/2012 11:19 AM, Andy Jin wrote:
Yeah, the UI needs to co-operate, for example outputs reasonable messages when timeout exceed, so that the degree of responsiveness is much better than a frozen UI.
My personal preference is to have a frozen UI since it forces developers to fix it fast. 

My ignorance, but why do we hang the UI while we are supposed to be a-synchronized? 

There are still a few places where we don't have an async. API available.  I mentioned cell editing and drag and drop in viewers, but there are others.  GdbConnectCommand is not one of them though and should be fixed :-)
Thanks,
Andy

From: Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Tuesday, 17 July, 2012 2:07 PM
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Why doesn't DSF-GDB timeout when it submits query?



IMO, timeouts are a band-aid solution: do you really prefer a stuttering UI to a frozen one.  I have to admit though sometimes even band-aids are useful ;-)

Cheers,
Pawel

On 07/17/2012 10:22 AM, Andy Jin wrote:
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



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top