-
Notifications
You must be signed in to change notification settings - Fork 721
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
JDK8 Windows SC_Softmx_JitAot_0_FAILED - Segmentation error vmState=0x0002000f #10984
Comments
this crash occur because of bogus O-slot in jit frame:
this problematic address GC check discovered the same bogus address in Monitor table too:
Passing investigation to JIT for now. Please let me know if I can help. |
@andrewcraik FYI |
It's a problem of missing gc map somewhere. Temp slot |
I've done a 120-job grinder, and not able to reproduce. |
I haven't found anything wrong with the jit code yet. All gc maps mark There's only one write to
The slot is stored in only one place, and there is only one instruction stores register to this slot, which is after monitor enter. If anything's wrong, I wonder if the register's value is corrupted during moniter enter. @dmitripivkine What was GC doing when the program crashed? Was it updating object references in stack frames? Is |
This is crash in Scavenger, so GC is scanning thread stack and copy discovered objects one by one. And problematic address pointed to zeros (mid large array) so it crashed an attempt to read object's class.
Yes, as soon as copy operation completes (see t2 - t6 pointed to Survivor already). The problematic slot has not been updated by GC, Scavenger crashed at first attempt to get object info
No. This object (use to be at
Monitor Table is the structure maintained by VM (I am not sure does JIT add elements to it too). It is located ( |
@gacholio Could you shed some light here?
+32786 will call jitMonitorEntry, which eventually calls VM helper.
gc map for this call is merged to the following gc map
I suspect the register is corrupted in the helper call, and we wrote the corrupted value to the jit slot. The corrupted value also shows up in monitor table, which won't be modified by the JIT I downloaded the sdk and core dump in |
I guess my first comment would be that being able to dereference There's no reason to think that the helper code is corrupting the value - they all use the same boilerplate code to save/update/restore the registers. |
If this only occurs on windows, it's possibly due to the differing C linkage (though the helper linkage does not change). On windows, RDI is preserved in the C linkage, so it will not be saved or restored in the fast path of jitMonitorEnter (no GC possible), only in the slow path. It's extremely likely that we hit the slow path given that the fast path is the same as the JIT inline path. Is this issue repeatable? |
Tried 120 jobs, no reproduce. |
Full helper disassembly:
|
The RDI value is used in the slow path (GC possible) case, so it's likely good on entry. I can still see no reason it would be corrupted if it is register mapped correctly. |
The gc map at the monitor entry call is merged to gc map with larger instruction offset. It's something we have been doing for years. Not sure if anything's wrong there, will have to check. Otherwise, just need to reproduce the failure first. |
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.system_x86-64_linux_Nightly_testList_1/17 Diagnostics, there is a core file: https://140-211-168-230-openstack.osuosl.org/artifactory/ci-eclipse-openj9/Test/Test_openjdk8_j9_extended.system_x86-64_linux_Nightly_testList_1/17/system_test_output.tar.gz 16.jvm4.stderr
|
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.system_x86-64_linux_Nightly_testList_0/56
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk11_j9_sanity.system_x86-64_windows_Nightly_testList_1/36
|
Looks like there is an attempt to copy object from |
The reason for crash is bad O-slot
|
Ah, it is even the same problematic method |
Hm, indeed. I wonder if it's a non-JITServer specific bug then. |
New occurrence in #14119 |
The problem in #14119: Object pointer
|
Failure link
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.system_x86-64_windows_Nightly/526/
To rebuild the failed tests in =https://ci.eclipse.org/openj9/job/Grinder, use the following links:
23:30:37 https://ci.eclipse.org/openj9/job/Grinder/parambuild/?JDK_VERSION=8&JDK_IMPL=openj9&BUILD_LIST=system&PLATFORM=x86-64_windows&TARGET=SC_Softmx_JitAot_0
Optional info
Failure output (captured from console output)
The text was updated successfully, but these errors were encountered: