RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

[Reingruber, Richard]

Hi Serguei,

> This looks reasonable to me.

Thanks!

> The only question is about the quality of this testing.
> How are we sure these errors are caused by races but not bugs in the GetLocalObject implementation?

I'm not sure. Unfortunately I cannot reproduce it even though I tried. I had 40
instances of the test running concurrently over night without failure. I did the
GetLocalObject call for every frame on stack while the target was sleeping in
Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal(). My best guess would be
that the harness methods on stack are compiled differently @Oracle, e.g. without
local variable table. Or the test is run with -Xcomp (tried that also).

Can we get the jtr file of the failure?

Would be nice if we could add some tracing to the vm.

Thanks, Richard.


From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
Sent: Mittwoch, 2. September 2020 20:06
To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
Subject: Re: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

Hi Richard,

This looks reasonable to me.
The only question is about the quality of this testing.
How are we sure these errors are caused by races but not bugs in the GetLocalObject implementation?

Thanks,
Serguei


On 9/2/20 07:37, Reingruber, Richard wrote:
Hi,

please help review this fix for  a TESTBUG in
serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java

Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8252593

With this change the JVMTI test agent silently accepts JVMTI_ERROR_INVALID_SLOT
as result of a JVMTI GetLocalObject() call.

The target frame of the call varies because the target thread is running. In
rare cases it might not be one of the many frames of
GetLocalWithoutSuspendTest.recursiveMethod() as intended but the frame of a static
method without parameters which the target thread might call after returning from all
the recursive calls. This would result in JVMTI_ERROR_INVALID_SLOT.

Anyway JVMTI_ERROR_INVALID_SLOT has to be expected and should be silently
ignored.

Furthermore I have corrected the type of the parameter waitCycles of
Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it
matches the declaration in GetLocalWithoutSuspendTest.java.

Thanks, Richard.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200903/667df81f/attachment.htm>