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.
debugger requests ThreadReference/SuspendCount from threadId of a thread which already exited. this causes ide to throw: java.lang.IllegalThreadStateException at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:45) at com.sun.tools.jdi.ThreadReferenceImpl.suspendCount(ThreadReferenceImpl.java:144) at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl.notifySuspended(JPDAThreadImpl.java:482) at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.notifySuspendAll(JPDADebuggerImpl.java:1058) at org.netbeans.modules.debugger.jpda.util.Operator$1.run(Operator.java:153) [catch] at java.lang.Thread.run(Thread.java:595) and additionaly breaks debugging session. It appears that this problem is caused by not refreshing the list of existing threads (call VirtualMachine/AllThreads) after a break point is reached and before ThreadReference/SuspendCount is requested. i.e.: an example of current JDWP command sequence (simplified) is: 1. VirtualMachine/AllThreads 2. ThreadReference/SuspendCount (called for each threadId) 3. VirtualMachine/Resume >> one of the threads exits here 4. Event/Composite (a Breakpoint with suspend_all policy was reached in debugee) >> here we should call VirtualMachine/AllThreads to refresh which thread are alive but don't 5. ThreadReference/SuspendCount (called on threadId of thread that exited after step 3.) resulting in error INVALID_THREAD This problem breaks debugging for a number of mobility emulators and needs to be addressed asap.
to reproduce: use WTK 2.2 with mobility pack and create hello world midlet sample project 1. set breakpoint in midlet constructor 2. set breakpoint in startApp() 3. start debugger 4. after debugger stops on breakpoint in constructor hit continue (resume vm) in the debugger 5. exception appears (thread which executed constructor exists before the startApp() is executed on a different thread)
JDI Javadocs is really bad. I does not say anything about when can I call this method. JDWP can send INVALID_THREAD error, but JDI does not reflect this in any declared thrown exception.
Please provide the build number. After the fix of issue #103732 the Operator should not be broken and debugging session should continue...
i built the ide from cvs myself on 2007-06-02 - i checked to make sure and Operator.java is at version 1.48 i.e. the fix for #103732 is included. it is possible that the emulator doesn't recover correctly.
after looking a bit closer there must be a stale thread reference left in the debugger somewhere because after the exception described before the debugging session continues and the debugger eventually does call VirtualMachine/AllThreads and receives an updated list of thread id's, however even after that the debugger continues to send ThreadReference/FrameCount & ThreadReference/SuspendCount requests with the original (non-existent) thread id and the debugee continues to return numerous INVALID_THREAD errors. this suggests that there is an additional problem where thread old expired thread ids are still used even after they aren't listed in response to VirtualMachine/AllThreads
Please include also JDK version to the bug reports. I've problems reproducing this, it works fine for me on JDK 1.6.0_02. I can call suspenCount() on thread which is in Zombie status and it returns 0. :-) I did not manage to get this exception. I'll try on JDK 1.5 after lunch...
Here is my setup: Product Version = NetBeans IDE Dev (Build 070602) Operating System = Linux version 2.6.18.8-0.3-bigsmp running on i386 Java; VM; Vendor; Home = 1.5.0_11; Java HotSpot(TM) Client VM 1.5.0_11-b03; Sun Microsystems Inc.; /home/kaja/java/jdk1.5.0_11/jre
It works the same way on JDK 1.5. Thus it seems to be unreproducible with JDI from standard J2SE. It looks like a bug of the mobility pack. What we can do is to call ThreadReference.status() and check it for zombie status. And if it's zombie, then do not call any other method on it. But if it will become zombie right after the check, we can not prevent from exceptions like this.
have you read my previous post? Mon Jun 4 15:54:13 +0000 2007 - i.e. to me it seems that the debugger doesn't update it's internal state and keeps sending requests to thread ids that no longer exist which would be the cause of this problem. I will try to reproduce the same steps with SE and see what kind of behavior i get.
Yes I did. But I wanted to reproduce the exception first. When it's P1 it should be reproducible... I know what's going on, we have a cache of threads and track their suspend status. To have the suspend status correct, we call notifySuspended() and notifyToBeResumed() on our thread objects. When the thread dies, it's called on a dead thread (zombie). This does not cause any problem in J2SE. It's removed from the cache after the thread is collected by GC. I'll fix this by checking the thread state as I wrote.
FYI: I've submitted http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6565188
We ignore zombie threads now, so it should be fixed. Please verify... /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/JPDADebuggerImpl.java,v <-- JPDADebuggerImpl.java new revision: 1.123; previous revision: 1.122
verified thank you for the prompt fix - great work. k