RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)"

[Chris Plummer]

On 9/26/18 11:07 AM, Gary Adams wrote:
> On 9/26/18, 1:40 PM, Chris Plummer wrote:
>> Hi Gary,
>>
>> Should the following comment come first, not after the join() call:
>>
>>  115             mt.join();
>>  116             // Wait till the other thread completes its execution.
> I'll move the comment up.
>>
>> Rather than using JVMTI to detect if the field is suspended, couldn't 
>> you have just set a static variable in callbackFieldAccess() and 
>> check it from isSuspended()?
> All of the other native calls take a thread and operate on it.
> It seemed reasonable to use the same check that popThreadFrame used.
>
>>
>> Before doing the fix, did you first check if the bug is easily 
>> reproduced by making is sleep for 1ms instead of 100ms?
> That's how I got the problem to reproduce.
> Switching to sleep(1) got 5 failures in 300 testruns.
Ok, and I assume you then tested the fix with the 1ms sleep? If so, then 
ship it. Otherwise do this testing first.

thanks,

Chris
>>
>> thanks,
>>
>> Chris
>>
>> On 9/26/18 7:55 AM, Gary Adams wrote:
>>> A race condition exists in hs203t003 between the main test thread and
>>> the processing in callbackFieldAccess processing. The main thread
>>> already includes a polling loop to wait for the redefine class 
>>> operation
>>> to be performed, but it does not wait for the following suspend thread
>>> operation to be completed.
>>>
>>> This changeset adds an additional wait for the suspend thread to 
>>> complete.
>>> It also checks the error returns from popThreadFrame and resumeThread
>>> to issue an additional error message if these native routines 
>>> returned an error.
>>>
>>>   Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/
>>>   Issue:  https://bugs.openjdk.java.net/browse/JDK-8210984
>>
>>
>>
>