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.
051003, Mustang b54, Linux. Pretty often when I am debugging, I will step over some line of code, or run to cursor, or something, and find that some but not all of the local vars in the Local Vars window have been evaluated. (I show the toString() column always.) Some of them will show just "Evaluating..." in blue. There is no apparent way to get out of this state; when it happens, Call Stack shows nothing, Continue is enabled but does nothing, etc. The only workaround is to shut down the VM using S-F5. This throws exceptions. Somehow, this bug always occurs just when I about to step into the line of code which would show me where *my* bug is. :-( It often makes the debugger useless for me, so should be P2 if it happens to anybody else. I don't believe the vars in question have especially difficult toString() impls; seems to happen even on the same classes which previously displayed just fine, and immediately. So might be some race condition?
Created attachment 25529 [details] Exceptions after shutting down VM; may be a symptom of this bug
This is likely http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6293795 It happens from time to time, but it seems that we can not do much about it. It just needs to be fixed in JDI...
OK, but is there some reasonable priority/severity set for it? Marked w/ 'netbeans' keyword? Maybe I'm using the debugger in an unusual way, but I don't think so, and this bug makes it be not very useful - back to System.err.println I guess. Any known workarounds?
I've just added 'netbeans' keyword to that bug. It has priority 3, but we were talking with Jim about it, we've provided a test-case and they know that it can cause the debugger session to freeze. A workaround is not to call any methods. Turn off "toString()" column and do not add method invocations into Watches view. It happens mainly in multi-threaded applications (it was not reproduced in a single-threaded app AFAIK).
Well, perhaps we can think of some workaround, since this happens to many people and it does not seem to be fixed soon in JDI. We have a periodic checks on suspended status of threads. This should be removed in the future, since it's not nice and hurts performance, but we can use it for the workaround for now. When we detect that all threads are suspended, but we think that the debugge is running, we know that we've miss some event that got lost in JDI. So, reopening, I'll try to prepare some workaround. I'll close again as "wontfix" if the workaround will not work reliably...
Well, it's not so simple - when the thread is resumed, it behaves like continue. This is not desired...
*** Issue 70642 has been marked as a duplicate of this issue. ***
I've spend some time by an analysis of what is happening. The not-responding invoke method JDI call seems to occur iff you have an application with at least two active threads, you perform steps in one thread and have a breakpoint in the other. What can happen is: After a step is finished in thread 1, a breakpoint is hit in thread 2 at the same time. (That can be verified by switching the current thread and viewing the call stack.) However, just the step event arrives, we get no breakpoint event at this point. When a method is invoked in this state, the breakpoint event unexpectedly arrives (although we are disabling all breakpoints temporarily). This suspends the VM, including the method invocation. Therefore we do not ever get the reply from the invoke method call. Since we know what exactly is going on now, we'll be able to make a workaround for this buggy behavior.
The workaround is implemented in trunk. Hopefully it will work fine: /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/JPDADebuggerImpl.java,v <-- JPDADebuggerImpl.java new revision: 1.96; previous revision: 1.95 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/util/Operator.java,v <-- Operator.java new revision: 1.40; previous revision: 1.39
I'm not able to reproduce this inside current trunk. Marking as verified. --------------- NetBeans IDE Dev (Build 200604121800) 1.6.0-beta2; Java HotSpot(TM) Client VM 1.6.0-beta2-b76 SunOS version 5.10 running on sparc en (nb); ISO646-US
Fix Review: This is a real problem caused by JDI bug (JDI fix in progress). Since the presented NB workaround has been verified, I suggest the integration to NB 5.5.
I have not seen this problem in trunk builds after the fix.
Created attachment 29865 [details] The textual diff of the fix.
Thanks for the review and verification, the fix is applied into 5.5 release: /shared/data/ccvs/repository/debuggerjpda/src/org/netbeans/modules/debugger/jpda/JPDADebuggerImpl.java,v <-- JPDADebuggerImpl.java new revision: 1.81.4.3.2.2; previous revision: 1.81.4.3.2.1 done /shared/data/ccvs/repository/debuggerjpda/src/org/netbeans/modules/debugger/jpda/util/Operator.java,v <-- Operator.java new revision: 1.38.10.1.2.1; previous revision: 1.38.10.1