RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)"
Gary Adams
gary.adams at oracle.com
Wed Sep 26 18:07:08 UTC 2018
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
>
>
>
More information about the serviceability-dev
mailing list