Bug 196375 - Hang trying to kill debugged process (EQ waiting for CallStackFrameImpl)
Hang trying to kill debugged process (EQ waiting for CallStackFrameImpl)
Status: RESOLVED FIXED
Product: debugger
Classification: Unclassified
Component: Java
7.0
PC Linux
: P3 (vote)
: 7.0
Assigned To: Martin Entlicher
issues@debugger
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-06 20:57 UTC by Jesse Glick
Modified: 2011-03-08 05:45 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump (29.58 KB, text/plain)
2011-03-06 20:57 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-03-06 20:57:44 UTC
Created attachment 106772 [details]
Thread dump

Dev build, Ubuntu. I had a NB instance running the debugger, and had suspended one of its thread to see a call stack. I then used File > Exit in the test VM, but it would not exit. In the dev instance, I remembered that this thread had been suspended, so I clicked Resume on it, but the target VM would still not exit. I tried to click Resume again but now the dev VM hung - see thread dump.
Comment 1 Martin Entlicher 2011-03-07 10:38:59 UTC
I was not able to reproduce the hang. The debugge always exits normally for me when I do File -> Exit even when there are suspended threads.

I'll fix the locking in AWT so that it does not freeze, but I do not think that we can resolve the case when target VM does not respond. Resume of the thread was not performed, because many threads are waiting at TargetVM.waitForReply(TargetVM.java:281).
Comment 2 Martin Entlicher 2011-03-07 12:55:42 UTC
I've fixed locking in changeset:   190487:1d900f71e0dd
http://hg.netbeans.org/main/rev/1d900f71e0dd

I did not reproduce the hang on several attempts, if you can reproduce it, please provide more detailed steps and I'll try to investigate. IMHO it can be a bug in the debugger backend.
Comment 3 Jesse Glick 2011-03-07 15:20:59 UTC
(In reply to comment #1)
> I'll fix the locking in AWT so that it does not freeze, but I do not think that
> we can resolve the case when target VM does not respond.

So long as the development IDE does not freeze, and the debugging session can be killed, I think it is OK.
Comment 4 Quality Engineering 2011-03-08 05:45:52 UTC
Integrated into 'main-golden', will be available in build *201103080000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1d900f71e0dd
User: mentlicher@netbeans.org
Log: #196375 Prevent from acessing lock under which we communicate with debuggee in AWT


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