Erik Gahlin wrote:
I also like to understand better.
Possibly my previous reply was not clear enough or I missed something there.
The test was to test JDK-6751643 as I cited in the last mail, here is
the info from JDK-6751643 to which this test was developed:
------
This bug can only occur if a debugger has multiple threads and calls any
of the following methods in one thread while simultaneously resuming the
same debuggee thread in a different debugger thread. Debuggers shouldn't
do this because it is a race condition and the result returned by these
methods will vary depending upon just where in the processing of these
methods the resume takes effect. EG, the frameCount() method could
return 6 in a case where the debuggee has already been resumed and there
are no frames.
------
To reproduce the bug, test did mainly 2 things by different threads:
1) received vm events and resumed vm, this was done by thread "Thread-1"
in the class TestScaffold which registered a listener and called the
following method:
/**
* Events handled directly by scaffold always resume (well, almost
always)
*/
public void eventSetComplete(EventSet set) {
// The listener in connect(..) resumes after receiving our
// special VMDeathEvent. We can't also do the resume
// here or we will probably get a VMDisconnectedException
if (!containsOurVMDeathRequest(set)) {
traceln("TS: set.resume() called");
set.resume();
}
}
2) called the method "check" in the class SimulResumerTarg, to see
whether a NullPointerException was thrown, the thread name was "test
resumer" (better to named as "checking thread"?)
So one thread was doing resume, another thread was doing check at same.
I added the code to see the different values of frames.size() at line 185:
for (i=0; i<10:i++) {
System.out.println("---frames.size(): "+frames.size());
Thhread.sleep(200);
}
if printing out frames, sometime we could see one more frame:
------------------ java.lang.Thread.yield()+-1 in thread instance of
SimulResumerTarg(name='Thread 2', id=109)
Shanliang
I looked at this failure before and I couldn't see what was wrong, not
in the test or product.
Erik
Jaroslav Bachorik skrev 3/27/14 4:49 PM:
On 27.3.2014 15:49, shanliang wrote:
Hi,
The call
thr.frames(0, frames.size() - 1);
suffers a synchronization issue, the size may be changed after
frames.size() returns.
Any idea why there is a synchronization issue? The code seems to be
intended to run only when a breakpoint is hit and the target thread
is suspended.
-JB-
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-6815126/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-6815126
Shanliang
