RFR: 6815126 intermittent SimulResumerTest.java failure

[Jaroslav Bachorik]

Thanks Shanliang, it is clear now.

The patch will get rid off the IOOBE but I have my doubts about what the 
test actually tests. It is supposed to make sure that certain operations 
will not throw NPE when the debugged thread is resumed (from a 
concurrent debugger thread) before the operation has managed to finish. 
However, there seems to be no synchronization logic between the thread 
invoking the operations and the thread resuming the paused debugged 
thread, relying only on hitting this condition by chance.

This test seems to be a good candidate for a thorough revision/rewrite.

-JB-

On 31.3.2014 11:26, shanliang wrote:
> 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
>>>
>>
>