This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I was debugging a remote Java application (I used the Attach... feature). The debugger stopped at a breakpoint (only one thread suspended). I needed to inspect some local objects so I switched to the Local Variables view. I could only see the blue labels "evaluating...". I waited a few seconds and then I given up and tried to get the values from the Watches view. I right-clicked and selected "New Watch..." - and the IDE stopped responding. I am attaching the thread-dump (produced by jstack). -- System info: NetBeans 080701, JDK 1.6.0_10-beta-b24, Linux (Ubuntu 8.04, 32-bit), Intel-based multi-core PC.
Created attachment 63819 [details] full thread dump (by jstack)
Correction: It was in NetBeans build 080629.
I can reproduce this bug when debugging a locally modified build of NetBeans 6.5 dev. To be exact, I have checked out Hg revision 477240a96fc6, modified several files in it (I will attach the source code patch) and built it. To reproduce: 1) Make a clone of Hg revision 477240a96fc6 of the "main" NetBeans source code repository. 2) Apply the attached patch to it. 3) Build it. I will refer to this custom build as to "NetBeans B". 4) Start NetBeans build 080629 (further referred to as "NetBeans A"). 5) In NetBeans A, open NetBeans source file junit/src/org/netbeans/modules/junit/output/JUnitOutputReader.java and set a line breakpoint on line 957 (it should contain text "closePreviousReport(true);"). 6) Start NetBeans B in debugging mode (see http://debuggercore.netbeans.org/docs/How-to-debug-NetBeans.html for how-to). 7) In NetBeans B, open the attached testing project and build it. 8) From NetBeans A, attach the debugger to NetBeans B (see the above mentioned how-to for more information). 9) In NetBeans B, run test class foo.SomeClassTest. 10) The test would run for at least 30 seconds. During that period, stop execution of the test. To stop the execution, select menu item "Build > Stop Build/Run" from the main menu. The breakpoint in NetBeans A should be hit. 11) In NetBeans A, open the Local Variables view and try to expand several nodes. Values of one or two nodes may be successfully evaluated but you will mostly see just "Evaluating..." or "Please wait...". If the evaluation does not finish soon, the debugger is not able to evaluate anything else. 12) In NetBeans A, open the Watches view and try to create a new watch in it from the context menu (mouse right-click, then select "New Watch..."). The IDE hangs from - this is the deadlock. Now both NetBeans A and NetBeans B are hang. If NetBeans A was started from a console, you can stop the JVM simply by pressing Ctrl-C in the console. NetBeans B cannot be shut down this way. I use command "kill -SIGABRT <pid>" to kill it.
Created attachment 63889 [details] NB source code patch against rev. 477240a96fcd
In description of step 5) of steps to reproduce, I forgot to note that the file JUnitOutputReader.java must be from the sources gained in steps 1) and 2).
Created attachment 63890 [details] simple testing project
NetBeans A had two com.sun.jdi.ObjectCollectedExceptions in the console at the moment of deadlock: SEVERE com.sun.jdi.ObjectCollectedException at com.sun.tools.jdi.JDWPException.toJDIException at com.sun.tools.jdi.ThreadReferenceImpl.threadGroup at o.n.m.debugger.jpda.models.ThreadsCache.exec ... SEVERE com.sun.jdi.ObjectCollectedException at com.sun.tools.jdi.JDWPException.toJDIException at com.sun.tools.jdi.ThreadReferenceImpl.jdwpStatus at com.sun.tools.jdi.ThreadReferenceImpl.isSuspended at o.n.m.debugger.jpda.models.JPDAThreadImpl.<init> at o.n.m.debugger.jpda.models.ObjectTranslation.createTranslation ... See the attachment for full call-stacks.
Created attachment 63894 [details] full call-stacks of exceptions in the console
I can reproduce this behaviour also with JDK 1.6.0_10-beta-b25 (i.e. the latest publicly available dev. build), JDK 6u6 (the latest stable release) and JDK 1.5.0_15 (the latest stable release of JDK 1.5). It seems to be 100% reproducible.
I just verified it works without any problem in NB 6.1.
Both ObjectCollectedExceptions have been fixed recently, but I am not sure if it alone could prevent the deadlock.
It's bad to access JDI from AWT. I have no idea why JDI does not respond. There are two requests sent to JDI concurrently in two threads. Maybe this is causing the problem. Thanks for steps to reproduce, they are needed to understand what's going on.
The deadlock is fixed in changeset: 102829:7257a8aa3088 http://hg.netbeans.org/main/rev/7257a8aa3088 AWT must not be involved in JDI calls. However, this only fixes the symptom of the blocking state of the debugger, the original problem why has debugger locked up needs to be found out.
Integrated into 'main-golden', will be available in build *200809200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7257a8aa3088 User: mentlicher@netbeans.org Log: #138824 - Prevent from freeze of AWT thread when JDI does not respond, collect the target VM context in a separate RP.
Problems with method invocations that did not finish should be already fixed in 6.8 builds. - http://hg.netbeans.org/main-silver?cmd=changeset;node=1f25085ff9d1 Since the deadlock was resolved, this should be fixed. Please verify.