crash vmState=0x0005ffff jitMethodTranslated #20257
Comments
pshipton
added
comp:jit
test failure
segfault
pshipton
added this to the Release 0.48 (Java 8, 11, 17, 21, 23) October refresh milestone
|
@hzongaro pls take a look. |
|
Issue Number: 20257 |
|
@a7ehuo, may I ask you to take a look at this? I wasn't able to build KCA, and I'm having difficulty doing much with the core file that was produced, so I'm not sure whether this is happening on the AOT load of One thing I can see is that it looks like the crash is happening on an inlined call to |
|
I also cannot get the backtrace from the core. So far I got more or less what Henry has found. I believe it crashes in the second call to openj9/runtime/codert_vm/CodertVMHelpers.cpp Line 230 in b279a6d
|
|
Grinder (ID 43741) run 150x |
|
FYI the original failure was found on the 0.48 build. |
|
0.48 build Grinder (ID 43777) run 150x |
|
I'll remove the milestone. |
pshipton
removed this from the Release 0.48 (Java 8, 11, 17, 21, 23) October refresh milestone
|
Should we assign to 0.49 until we are sure it's no longer an issue? |
|
If it's seen enough I will add it back to a milestone. Until it's seen again it doesn't seem there is anything to do. |
pshipton
added this to the Release 0.48 (Java 8, 11, 17, 21, 23) October refresh milestone
|
Another one, different platform. I'll put it back in 0.48 in case we can progress it from this. https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_ppc64le_linux_Nightly_testList_0/216/ - cent9-ppc64le-6 |
pshipton
changed the title
|
I looked at the core from ppc64le. There is no backtrace [1]. This crash looks same as the previous one. It crashes because it dereferences a NULL openj9/runtime/codert_vm/CodertVMHelpers.cpp Lines 229 to 230 in 1153568 Same as previous crash, Based on the logic inside With my limited knowledge, I don't think the JIT modifies iteration 0 [3]
iteration 1 [4] iteration 2 [5] iteration 3 [6] iteration 4 [7] iteration 5 [8] [1] [2] [3] [4] [5] [6] [7] [8] |
|
The only thing that comes to mind is there could be an issue if a class was being loaded while that method is called. FYI @gacholio |
|
If the thread does not have exclusive, there certainly could be new classes loaded during the loop. |
Just trying to understand, do you mean something like acquireVMAccessNoSuspend before calling inline void acquireVMAccessNoSuspend(J9VMThread *vmThread)
{
vmThread->javaVM->internalVMFunctions->internalAcquireVMAccessWithMask(vmThread, J9_PUBLIC_FLAGS_HALT_THREAD_ANY_NO_JAVA_SUSPEND);
} |
|
We may need to add a mutex for the traversal link uses. Exclusive and VM access act like a mutex, but it would be pretty heavy-handed to use that in this case. |
|
Looks like updates are protected with |
|
jitMethodTranslated is called in two places in TR::CompilationInfo::compilationEnd. Its implementation and where they are called have not been changed for a few years. @mpirvu I'm wondering if you see any concerns of calling (1) openj9/runtime/compiler/control/CompilationThread.cpp Line 10468 in 8357d17 (2) openj9/runtime/compiler/control/CompilationThread.cpp Line 10586 in 8357d17 |
|
Marius is on vacation. Please ignore my last comment. @gacholio I have a change that wraps the loop inside I looked at how other parts of VM traverse subclass link such as in verifyJ9ClassSubclassHierarchy or initializeClassLinks. It doesn't look obvious to me that they acquire classTableMutex. Another question is why it would be required in jitMethodTranslated? |
|
It should probably be acquired in all of the reader cases you've found. |
|
After taking a further look at verifyJ9ClassSubclassHierarchy and initializeClassLinks. I think these two should be fine that they don't need to acquire (1) verifyJ9ClassSubclassHierarchy
openj9/runtime/vmchk/vmcheck.c Lines 188 to 200 in 70f99fd
openj9/runtime/vm/createramclass.cpp Lines 2582 to 2583 in 70f99fd |
|
Your change looks correct to me. |
|
Issue Number: 20257 |
1 similar comment
|
Issue Number: 20257 |
Fixes: eclipse-openj9#20257 Signed-off-by: Annabelle Huo <[email protected]>
|
Re the failure #20257 (comment) |
|
Got one in the 0.48 release, where we didn't apply the fix. |
Fixes: eclipse-openj9#20257 Signed-off-by: Annabelle Huo <[email protected]>
Fixes: eclipse-openj9#20257 Signed-off-by: Annabelle Huo <[email protected]>
Fixes: eclipse-openj9#20257 Signed-off-by: Annabelle Huo <[email protected]>
https://openj9-jenkins.osuosl.org/job/Test_openjdk11_j9_sanity.system_aarch64_linux_Release_testList_1/110
PatModImg_PlatMod_0
vmState [0x5ffff]: {J9VMSTATE_JIT} {Illegal optimization number}https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk11_j9_sanity.system_aarch64_linux_Release_testList_1/110/system_test_output.tar.gz
The text was updated successfully, but these errors were encountered: