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