Community
Participate
Working Groups
This bug was exposed as a result of the fix for installing breakpoints in too many classes (a breakpoint in class Hello would result in a breakpoint being installed in Hello2). It appears to have been merely exposed by the fix, not caused by it. 1. Create the two classes which follow and place breakpoints where indicated in comments. 2. Debug Hello to the first breakpoint. 3. Click resume. 4. Note that the second breakpoint is not hit. Alternatively: 1. Same as above. 2. Same as above. 3. Step over the System.out call and the instantiation of Hello2 4. Note that after stepping over the instantiation, the thread was somehow resumed such that the call to Hello2#foo() is made and the breakpoint in Hello2 is hit. public class Hello() { public static void main(String[] args) { Hello h= new Hello(); h.foo(); } public void foo() { System.out.println("Foo!"); // place breakpoint here Hello2 h2= new Hello2(); h2.foo(); } } public class Hello2 { public void foo() { System.out.println("Foo2!"); // place breakpoint here } }
In the latest code stream, I have no problem. I recently changed the implementation of stepping/dropping, etc. I do not know if I fixed this as a side effect.
The bug still exists when I try the example on Linux. I tested this on WinNT, however, and it worked correctly. Seems this is a Linux-only bug?
We've managed to reproduce this bug on Windows, but only while debugging it (with breakpoints in the host). We suspect we've found the root of the problem: Two sets of ClassLoadEvents are being fired when Hello2() is loaded. Suspect the event flow is: 1. Receive ClassLoadEventSet. Install breakpoints, resume thread. 2. Receive BreakpointEvent. Handle as usual. 3. Receive duplicate ClassLoadEventSet. Reinstall breakpoints, resume thread. No sooner has the breakpoint been hit, than we are resuming the thread. Investigation continues.
It wasn't that we were receiving multiple EventSets for the class load, but that we were resuming the same thread for each event in the EventSet. So the interaction looked like: - VM suspends - VM fires ClassLoadEvent set (2 events) - EventDispatcher handles event set and calls EventSet.resume() - EventSetImpl, iterating over the events in the set, resumes the thread for the first class load event. - Thread resumes on VM and hits a breakpoint - VM suspends and fires breakpoint event - EventSetImpl, still iterating over the events in the set, resumes the thread (again) for the second class load event - VM resumes and hits the second breakpoint The EventSetImpl has been fixed to fire only one resume event per thread per call to EventSetImpl#resumeThreads()
Please verify.
Verified.
*** Bug 5083 has been marked as a duplicate of this bug. ***
*** Bug 5234 has been marked as a duplicate of this bug. ***
