RFR: 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT
Richard Reingruber
rrich at openjdk.java.net
Tue Sep 15 13:37:28 UTC 2020
On Sat, 12 Sep 2020 23:19:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> Continuing review [1] after transition to Git/Github.
>
> I still cannot reproduce the issue.
>
> RFC on alternatives:
>
> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT
> 2. Don't ignore JVMTI_ERROR_INVALID_SLOT but integrate the rest of this patch. If the test still fails with
> JVMTI_ERROR_INVALID_SLOT we will at least know the depth of the frame. 3. Add trace code to VM_GetOrSetLocal in
> !PRODUCT or ASSERT configurations depending on an option or property.
> Any other ideas?
>
> I'm in favour of 1.
>
> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032876.html
Thanks @iignatev for providing the hint that helped finding the cause for the JVMTI_ERROR_INVALID_SLOT
https://bugs.openjdk.java.net/browse/JDK-8252593?focusedCommentId=14368599&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14368599
I would like to take a different approach now for fixing this by making sure the JVMTI GetLocalObject() call refers to
one of the recursiveMethod frames on stack.
How to do that? Can I close this PR and create a new branch JDK-8252593-2 and then a new PR?
-------------
PR: https://git.openjdk.java.net/jdk/pull/142
More information about the serviceability-dev
mailing list