Community
Participate
Working Groups
We create a ClassPrepareRequest for java.lang.Error for our "Suspend on compilation errors" feature. The ClassPrepareEvent comes to us with a ThreadID of 0, which, according to JDWP spec, means null. We've previously assumed that an event could never come from a "null" thread. However, closer inspection of the JDWP spec yielded the following on the topic of the threadID field in a ClassPrepareEvent: "Preparing thread. In rare cases, this event may occur in a debugger system thread within the target VM. Debugger threads take precautions to prevent these events, but they cannot be avoided under some conditions, especially for some subclasses of java.lang.Error. If the event was generated by a debugger system thread, the value returned by this method is null, and if the requested suspend policy for the event was EVENT_THREAD all threads will be suspended instead, and the composite event's suspend policy will reflect this change." EventSetImpl.resumeThreads() needs to handle a null thread. When the thread is null, it should resume the entire VM.
Fixed. Please verify.
Does this not have to be handled in the case when there is more than one event?
That was an oversight on my part. I've updated EventSetImpl to resume the entire VM if any event in the set has a null thread. Please verify (Darin W).
Verified. Released change to 2.0.1 (and is in HEAD)