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

[Gary Adams]

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