-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JDK21 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java Segmentation error vmState=0x00040000 #17712
Comments
Uber issue: eclipse-openj9/openj9#17671 Issues for individual failures: - eclipse-openj9/openj9#17711 - eclipse-openj9/openj9#17712 - eclipse-openj9/openj9#17713 - eclipse-openj9/openj9#17715 - eclipse-openj9/openj9#17716 - eclipse-openj9/openj9#17717 - eclipse-openj9/openj9#17718 Signed-off-by: Babneet Singh <[email protected]>
Uber issue: eclipse-openj9/openj9#17671 Issues for individual failures: - eclipse-openj9/openj9#17711 - eclipse-openj9/openj9#17712 - eclipse-openj9/openj9#17713 - eclipse-openj9/openj9#17715 - eclipse-openj9/openj9#17716 - eclipse-openj9/openj9#17717 - eclipse-openj9/openj9#17718 Signed-off-by: Babneet Singh <[email protected]>
There is a crash in openj9/runtime/jvmti/jvmtiHeap.c Line 891 in a2c8e15
In the above code, Test code: @amicic @dmitripivkine @LinHu2016 Would you have guidelines on how [GDB] Stacktrace during the crash
|
@amicic @dmitripivkine @LinHu2016 Any updates or guidance on how to resolve this issue? |
I don't know answer to this question, I don't know enough what VM is doing with VTs:
And yes, |
@babsingh the jvmti code expects the walkthread to be a carrier thread. See I general I dont think continuations should ever need to scan JNI_LOCALS, since it its unmounted it cannot have a JNI frame. This eliminates one requirement for TID. The other is |
Unmounted virtual threads cannot have have a JNI frame. JNI_LOCAL requests should be ignored for unmounted virtual threads. STACK_LOCAL requests use 0 for TID since it is not currently feasible to derive this information for unmounted virtual threads. Related: eclipse-openj9#17712 Signed-off-by: Babneet Singh <[email protected]>
@tajila #18020 has the above changes. We avoid the segfault but the test still fails. We fail the following scenarios: Test source codeTest output with OpenJ9 + #18020
Test output with the RI
|
The reported |
|
@llxia In adoptium/aqa-tests#4738, we added an exclude for
|
I think so. |
re #17712 (comment): adoptium/aqa-tests#4744 individually excludes each |
@LinHu2016 Can you post in this issue so we can assign this issue to you? |
For the below is that test result of the latest local build with PR #18214
|
threadObject is required in jvmtiFollowReferences to get thread specific details such as the TID. So, threadObject needs to be passed via walkContinuationStackFrames so that it is accessible in jvmtiFollowReferences. walkContinuationStackFrames is invoked either for a [1] J9VMContinuation in the Continuation object or [2] J9VMThread->currentContinuation In [1], if the Continuation is fully mounted, then it stores the state of the CarrierThread. Otherwise, it stores the state of the VirtualThread. In [2], if J9VMThread->currentContinuation is not NULL, then it stores the state of the CarrierThread because the VirtualThread is mounted on the J9VMThread. The CarrierThread is retrieved from J9VMThread->carrierThreadObject. We have assumed that the state of the Continuation or J9VMContinuation doesn't change while walkContinuationStackFrames is invoked i.e. the VirtualThread shouldn't be mounted or unmounted. Otherwise, the values of the VirtualThread and CarrierThread objects accessed via the Continuation object and J9VMThread->carrierThreadObject can vary and cause a crash during walkContinuationStackFrames. Related: eclipse-openj9#17712 Signed-off-by: Babneet Singh <[email protected]>
@gacholio After looking at Can we actually rely on It looks like when we call @LinHu2016 Is there a reason why we dont just do a stack walk in |
As you say, stack-based refs are just O slots reported by the stack walk. |
@TobiAjila GC does two stack walks, one for normal thread java stack, another one is only for mounted virtual thread case - scan currentContinuation(carrierthread stack, we don't stackwalk for mounted continuation during GC heap walk). |
@LinHu2016 The test is failing because we are not finding objects on the stack. The RI is able to find them. We should try to match their behaviour for JVMTI. |
Hi @tajila , for regular GC scan, we have scanned mounted continuation( inside is carrier thread java stack) during root scanning(threads scan), so scanning mounted continuation in heap scanning is duplicated( also for some GC processing, it doesn't allow scanning second time such as compaction), we can treat JVMTI heap walk(referencechainwalker) differently, but I need to confirm if JVMTI is ok for duplicated scan or we need to stop scan currentContinuation during root scanning(thread scanning) for JVMTI case. |
Scan all slots
|
|
|
@LinHu2016 Based on the snippets above, I couldn't find where a stack walk was occurring. |
Are you asking about stacks for regular (carrier) threads or unmounted VTs? |
@tajila
|
|
Per discussion with @LinHu2016 , the cause of this test failure is not the JNI local ref not being found by GC, rather GC have located the object via stack walking but returned the reference with an incorrect type, hence the test code wasn't able to find the JNI ref expected from API. |
Failure link
From an internal build(
rhel8x86-rtp-rt2-1
):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
Created from
FYI @babsingh
The text was updated successfully, but these errors were encountered: