Bugzilla – Full Text Bug Listing
| Summary: | Step Debugger throws Timeout Exception on Windows | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Igal Sapir <igal> |
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | igal, loskutov, sarika.sinha |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
| Attachments: | |||
Created attachment 259501 [details]
Screenshot of Error Modal MessageBox
Created attachment 259502 [details]
Screenshot of the full Eclipse Window with Error Modal Box
Created attachment 259503 [details]
Screenshot of Eclipse SDK Installation Details
I originally reported this in https://bugs.eclipse.org/bugs/show_bug.cgi?id=94452 -- which seems related and was closed as fixed for Eclipse 4.6 M4, but was advised to open a new ticket. This issue was tested with Eclipse 4.6 M4 and still shows the problem. Thank you. Andrey, Do you want to look at this ? Igal, can you please clesr the error log view, restart your case and after timeout error occurs attach here all new errors from the log. Created attachment 259534 [details]
Screenshot showing empty Error Log Window
The error log is empty.
Am I looking at the correct error log?
Is there a setting I should change for more verbose logging?
While the error dialog is shown, can you create the JVM dump via jstack? Just curiuos about the threads running at that moment in the Eclipse. P.S. I've set bug version to 4.5 but please set it to the first version you see the problem with that setup. Created attachment 259542 [details]
Thread Dump while Modal Error Box is Open
I don't have older versions of Eclipse installed, but I have experienced this issue since the old days of Eclipse Juno, possibly even Eclipse Indigo (at least since 2011).
My "solution" back then was to use IntelliJ IDEA instead of Eclipse, because other committers to the project are on a Mac and do not suffer from this issue, and IntelliJ does not suffer from this problem.
See attached Thread Dump.
"Packet Receive Manager" #582 daemon prio=5 os_prio=0 tid=0x000000001fb73000 nid=0xb78 runnable [0x000000002afcf000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.DataInputStream.readInt(Unknown Source) at org.eclipse.jdi.internal.connect.SocketConnection.readPacket(SocketConnection.java:69) - eliminated <owner is scalar replaced> (a java.io.DataInputStream) at org.eclipse.jdi.internal.connect.PacketReceiveManager.readAvailablePacket(PacketReceiveManager.java:300) at org.eclipse.jdi.internal.connect.PacketReceiveManager.run(PacketReceiveManager.java:87) at java.lang.Thread.run(Unknown Source) Trying to get anything from remote server ? (In reply to Igal Sapir from comment #0) > Please note: > > (1) My colleague debugs this project in Eclipse Kepler on a Mac with no issue That's interesting, I've initially missed that. Here I think immediately on different firewall rules / proxies etc in different OS you could use. > (2) There is a daemon thread running in the application (not the thread on > which I'm setting the breakpoint). When I disable the daemon thread then > there is no issue. Interesting is to know *what* this thread is doing while you are debugging? Can you make a dump of the application while it is waiting on the breakpoint and can you point to the code of that daemon thread? Just wondering if this thread "steals" or blocks the network resources or something similar on Windows. (In reply to Sarika Sinha from comment #11) > > Trying to get anything from remote server ? I am not sure, but I don't see any lucee.* code in the stack trace, only Eclipse? The application checks in the background for updates and other things, so it's possible that this is what we see here. That, by the way, is controlled by the daemon thread (item (2) in the OP), which when disabled the timeout doesn't take place. (In reply to Andrey Loskutov from comment #12) > That's interesting, I've initially missed that. Here I think immediately on > different firewall rules / proxies etc in different OS you could use. I really doubt that. The application runs fine when I don't set a breakpoint, or when the daemon thread mentioned below is disabled. If there was a firewall issue then I would have problems without the breakpoint either. I allowed Eclipse, of course, in the Windows Firewall. > Interesting is to know *what* this thread is doing while you are debugging? > Can you make a dump of the application while it is waiting on the breakpoint > and can you point to the code of that daemon thread? Just wondering if this > thread "steals" or blocks the network resources or something similar on > Windows. Do I need to do a different kind of Thread Dump? Or is it just that you're not sure which thread in the dump is the daemon thread of the application? Please advise. Thank you. I might be missing something with the Thread Dumps. Is there a different process that I need to do the dump on? Most of the code in the application I'm debugging is in a package named "lucee". How come I don't see anything with "lucee.*" in the Thread Dump? After waiting a while longer, two exceptions showed up on the Error Log:
eclipse.buildId=4.6.0.I20151209-2300
java.version=1.8.0_71
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86_64
org.eclipse.jdt.debug
Error
Thu Feb 04 08:43:14 PST 2016
Internal error logged from JDI Debug:
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 17272.
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:193)
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:204)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:227)
at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:263)
at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:245)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames(JDIThread.java:675)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:574)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:646)
at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.supportsDropToFrame(JDIStackFrame.java:642)
at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.canDropToFrame(JDIStackFrame.java:610)
at org.eclipse.debug.internal.core.commands.DropToFrameCommand.isSteppable(DropToFrameCommand.java:35)
at org.eclipse.debug.internal.core.commands.StepCommand.isExecutable(StepCommand.java:46)
at org.eclipse.debug.core.commands.AbstractDebugCommand$UpdateJob.run(AbstractDebugCommand.java:101)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
eclipse.buildId=4.6.0.I20151209-2300
java.version=1.8.0_71
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86_64
org.eclipse.jdt.debug
Error
Thu Feb 04 08:43:08 PST 2016
Internal error logged from JDI Debug:
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 17270.
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:193)
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:204)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:227)
at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:263)
at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:245)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames(JDIThread.java:675)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:574)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:646)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.getTopStackFrame(JDIThread.java:1329)
at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.isTopStackFrame(JDIStackFrame.java:1033)
at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.canStepInto(JDIStackFrame.java:224)
at org.eclipse.debug.internal.core.commands.StepIntoCommand.isSteppable(StepIntoCommand.java:27)
at org.eclipse.debug.internal.core.commands.StepCommand.isExecutable(StepCommand.java:46)
at org.eclipse.debug.core.commands.AbstractDebugCommand$UpdateJob.run(AbstractDebugCommand.java:101)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Session Data:
eclipse.buildId=4.6.0.I20151209-2300
java.version=1.8.0_71
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86_64
Does the stack trace I posted a month ago give you any valuable information? Is there anything else I can help with in debugging this issue? (In reply to Igal Sapir from comment #17) > Does the stack trace I posted a month ago give you any valuable information? No. > Is there anything else I can help with in debugging this issue? Yes. Create a jstack dump of your application you are trying to debug (not Eclipse!) while this deamon thread is running at the moment you receive timeout at Eclipse side. If the application is open source, point to the source code of that deamon thread. If not, please provide here at least an idea what this thread is doing. > Create a jstack dump of your application you are trying to debug (not Eclipse!) while this deamon thread is running at the moment you receive timeout at Eclipse side.
How do I do that?
> Create a jstack dump of your application you are trying to debug (not Eclipse!)
Can anyone advise how to do this?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Running a multi threaded application on Windows, the debugger throws Timeout Exceptions when stepping to the next frame. The exception is shown as a modal MessageBox and I can not see a stack trace anywhere. This has been an issue with versions from at least the past five years, and has been verified to exist in the most recent build -- Eclipse Neon 4.6 M4. Please note: (1) My colleague debugs this project in Eclipse Kepler on a Mac with no issue (2) There is a daemon thread running in the application (not the thread on which I'm setting the breakpoint). When I disable the daemon thread then there is no issue. To reproduce: (a) Download and import the three projects from github: "loader" and "core" projects from https://github.com/lucee/Lucee "debug" project from https://github.com/lucee/debug (b) Debug as Java Application the class RunAsJavaApplication.java in the debug project, i.e. https://github.com/lucee/debug/blob/master/src/main/RunAsJavaApplication.java This would start an embedded Jetty on localhost:8080 (c) Set a breakpoint anywhere in the core project, e.g. at https://github.com/lucee/Lucee/blob/master/core/src/main/java/lucee/runtime/functions/dateTime/Now.java#L35 (d) Create a CFML script file in the debug projects "web" directory, e.g. "time.cfm" with a line of code that calls the breakpointed location. If your breakpoint is on the Now() function as suggested in item (c) above then this line would suffice: <cfoutput>The time is #Now()#</cfoutput> So you will have that line in the file ${debug-project}/web/time.cfm (e) Launch that file with your browser by pointing it to http://localhost:8080/time.cfm (f) Wait about a minute and then step through the frames at a reasonable pace. On the next Step attempt (or Resume) after about a minute of the initial breakpoint hit you will see the error.