RFR: 6815126 intermittent SimulResumerTest.java failure

[shanliang]

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
>>
>