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
