Bug 138824 - Deadlock when evaluating local variables
Deadlock when evaluating local variables
Status: RESOLVED FIXED
Product: debugger
Classification: Unclassified
Component: Java
6.x
PC Linux
: P3 (vote)
: 6.x
Assigned To: Martin Entlicher
issues@debugger
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-02 15:24 UTC by Marian Petras
Modified: 2009-08-26 16:28 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
full thread dump (by jstack) (25.80 KB, text/plain)
2008-07-02 15:25 UTC, Marian Petras
Details
NB source code patch against rev. 477240a96fcd (34.65 KB, patch)
2008-07-03 12:42 UTC, Marian Petras
Details | Diff
simple testing project (9.01 KB, application/x-compressed)
2008-07-03 13:01 UTC, Marian Petras
Details
full call-stacks of exceptions in the console (1.55 KB, text/plain)
2008-07-03 15:32 UTC, Marian Petras
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Petras 2008-07-02 15:24:02 UTC
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.
Comment 1 Marian Petras 2008-07-02 15:25:01 UTC
Created attachment 63819 [details]
full thread dump (by jstack)
Comment 2 Marian Petras 2008-07-02 15:28:22 UTC
Correction: It was in NetBeans build 080629.
Comment 3 Marian Petras 2008-07-03 11:30:32 UTC
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.
Comment 4 Marian Petras 2008-07-03 12:42:42 UTC
Created attachment 63889 [details]
NB source code patch against rev. 477240a96fcd
Comment 5 Marian Petras 2008-07-03 12:46:45 UTC
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).
Comment 6 Marian Petras 2008-07-03 13:01:13 UTC
Created attachment 63890 [details]
simple testing project
Comment 7 Marian Petras 2008-07-03 13:05:14 UTC
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.
Comment 8 Marian Petras 2008-07-03 15:32:04 UTC
Created attachment 63894 [details]
full call-stacks of exceptions in the console
Comment 9 Marian Petras 2008-07-03 15:34:15 UTC
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.
Comment 10 Marian Petras 2008-07-03 15:41:14 UTC
I just verified it works without any problem in NB 6.1.
Comment 11 Daniel Prusa 2008-07-25 13:40:42 UTC
Both ObjectCollectedExceptions have been fixed recently, but I am not sure if it alone could prevent the deadlock.
Comment 12 Martin Entlicher 2008-09-04 15:31:44 UTC
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.
Comment 13 Martin Entlicher 2008-09-19 13:16:46 UTC
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.
Comment 14 Quality Engineering 2008-09-20 05:34:39 UTC
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.
Comment 15 Martin Entlicher 2009-08-26 16:28:43 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo