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 17:03:14 UTC 2018
The native code for popThreadFrame and resumeThread
already set the failed agent status. These incremental steps
are non fatal as far as the test is concerned. I even saw some
test logs where the popThreadFrame failed, but the
resumeThread succeeded, because the thread was suspended
by that time.
Best to save the code cleanup to a changeset specifically targetted
at the cosmetic changes.
On 9/26/18, 12:42 PM, JC Beyler wrote:
> Hi Gary,
>
> Should you not also fail the test if the test fails at popping or
> resuming the thread?
>
> Apart from that looks good to me (I would remark normally that I'm
> getting rid of the NSK_CPP_STUBs so you could just jump the gun and
> remove it directly but this is consistent with the current code base
> and my scripts will get to it eventually...).
>
> Thanks,
> Jc
>
> On Wed, Sep 26, 2018 at 7:54 AM Gary Adams <gary.adams at oracle.com
> <mailto:gary.adams at oracle.com>> 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/
> <http://cr.openjdk.java.net/%7Egadams/8210984/webrev.00/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8210984
>
>
>
> --
>
> Thanks,
> Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180926/3a7b0bf9/attachment.html>
More information about the serviceability-dev
mailing list