Community
Participate
Working Groups
Build 3.1 20050126 After upgrading to 20050125, I am quite often seeing hangs during debug process (after hitting a breakpoint, some step action causes a freeze). There doesn't seem to be a specific pattern. Usually terminating/restarting would work. org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 104515 at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:160) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:169) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:174) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:187) at org.eclipse.jdi.internal.ThreadReferenceImpl.frame(ThreadReferenceImpl.java:140) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrame(JDIThread.java:575) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.getUnderlyingStackFrame(JDIStackFrame.java:1000) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.getUnderlyingMethod(JDIStackFrame.java:228) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.isNative(JDIStackFrame.java:793) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.supportsDropToFrame(JDIStackFrame.java:584) at org.eclipse.jdt.internal.debug.ui.actions.DropToFrameButton.selectionChanged(DropToFrameButton.java:62) at org.eclipse.ui.internal.PluginAction.refreshEnablement(PluginAction.java:195) at org.eclipse.ui.internal.PluginAction.selectionChanged(PluginAction.java:267) at org.eclipse.ui.internal.PluginAction.selectionChanged(PluginAction.java:278) at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:163) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1051) at org.eclipse.core.runtime.Platform.run(Platform.java:747) at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:161) at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:1676) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1358) at org.eclipse.debug.internal.ui.views.RemoteTreeViewer.deferSelection(RemoteTreeViewer.java:305) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleSuspendThreadEvent(LaunchViewEventHandler.java:237) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleSuspendEvent(LaunchViewEventHandler.java:204) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleDebugEvents(LaunchViewEventHandler.java:123) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler$EventProcessingJob.runInUIThread(AbstractDebugEventHandler.java:103) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:96) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:118) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2854) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2518) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1584) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1550) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:288) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:144) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:102) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:225) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:274) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:255) at org.eclipse.core.launcher.Main.run(Main.java:811) at org.eclipse.core.launcher.Main.main(Main.java:795)
The action should update in the background to avoid blocking the UI thread.
filed bug 85966 to handle selectionChanged() in background thread.
Phillippe, Are you still getting these Timeouts? I suspect this may be the same as bug #87144.
*** Bug 89064 has been marked as a duplicate of this bug. ***
*** Bug 84495 has been marked as a duplicate of this bug. ***
*** Bug 85842 has been marked as a duplicate of this bug. ***
*** Bug 87144 has been marked as a duplicate of this bug. ***
*** Bug 88197 has been marked as a duplicate of this bug. ***
*** Bug 81653 has been marked as a duplicate of this bug. ***
Another example timeout: org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 11567. RemainingTime: 0 Received: 46 Received Queue: [5830 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 10814 10815 10816 10817 10818 10819 10820 10821 10822 10823 10824 10825 10826 10827 10828 10829 10830 10831 10832 10833 10834 10835 10836 10837 10838 10839 10840 10841 10842 10843 10844 10845 ] at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply (PacketReceiveManager.java:175) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply (PacketReceiveManager.java:185) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:174) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames (ThreadReferenceImpl.java:187) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames (ThreadReferenceImpl.java:171) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames (JDIThread.java:500) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames (JDIThread.java:412) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames (JDIThread.java:476) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.supportsDropToFrame (JDIStackFrame.java:573) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.canDropToFrame (JDIStackFrame.java:544) at org.eclipse.debug.internal.ui.actions.DropToFrameActionDelegate.isEnabledFor (DropToFrameActionDelegate.java:81) at org.eclipse.debug.internal.ui.actions.AbstractDebugActionDelegate.getEnableStat eForSelection(AbstractDebugActionDelegate.java:392) at org.eclipse.debug.internal.ui.actions.AbstractDebugActionDelegate.update (AbstractDebugActionDelegate.java:244) at org.eclipse.debug.internal.ui.actions.DropToFrameActionDelegate.access$0 (DropToFrameActionDelegate.java:1) at org.eclipse.debug.internal.ui.actions.DropToFrameActionDelegate$UpdateJob.run (DropToFrameActionDelegate.java:43) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:67)
Proposals: * We should throw away responses for requests that have timed out. * We should serialize label jobs from the same target to avoid having mulitple jobs attempting to retrieve labels at once for the same target
haven't seen any Timeouts (or new bug reports) for a while. Changed PacketReceiveManager to maintain a list of packets that have timed out so that those packets can be thrown out when/if they are eventually received. Also reduced the error message back to a reasonable size Changes to ConnectMessages.properties and PacketReceiveManager
Darin, please verify
Verified.
Also see bug 94452. We have a potential fix for 3.1.1.
