-
Notifications
You must be signed in to change notification settings - Fork 729
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 Segmentation error vmState=0x00000000 #15338
Comments
I was able to repeat it on 0.33 and 0.32 fairly quickly. |
@connglli I'm not sure how you are finding these problems. Do you think there are going to be many more? |
Hi @pshipton, indeed what we have reported by far are obviously unique bugs of OpenJ9. Hope to improve the quality f OpenJ9. Not sure if there are MUCH more, but there are still some in our hands. We are still working on them (many are not crashes; miscompilations instead) such that we only report unique ones and don't smash your issuetracker. |
@mpirvu : could you have someone triage this crash in sampleMethod() please? |
@dsouzai since you recently looked at the sampling code, could you please investigate this crash? Test case is provided and problem is reproducible. Thanks |
@connglli do you mind uploading your JDK? I'm not able to reproduce the crash, and the coredump can really only be analyzed with the exact build that generated it. If you built it yourself, could you ensure that it contains the debug symbols; if you got it from somewhere, could you point me to that location? |
I was chatting with dsouzai and he found a local JVM that could reproduce the crash. |
Thanks @connglli, I'm downloading your build anyway because I'm seeing some inconsistent things in my repro. At the time of the crash, the ouput looks similar to yours. However, when I load the core in gdb I'm seeing:
Looking at the crashing instruction in
Given that r14 is the J9VMThread linked list that we're iterating over, and that at the start of the loop, the value of the J9JavaVM is stored into r13
So here it looks like the list of J9VMThreads is bad. Will investigate further to see if I can diagnose the crash in |
I'm not particularly sure what's going on. Every time I reproduce the crash, the crash output will say one thing, but the coredump will say another. Specifically, the crash will say something like:
but when I use gdb to look at the core:
the cause being the bad linked list of J9VMThread pointers. Additionally, whenever I run the test under gdb, I have never seen the crash in The bad address (according to the core file) is:
where r14= As such, it doesn't look like a JIT issue from what I've seen so far. @pshipton could you ask someone from the VM team to take a look? |
Some additionally information; if we start looping from the main thread:
We eventually see that
which means that |
Also @connglli I don't know what the expected output of the test should be, but whenever I run it, if it doesn't crash, it will print
and seem to hang. Is this expected? |
Absolutely not expected. The program should not hang, instead it should exit normally. This is the output of HotSpot JDK8/11/17 and Android ART:
|
Also if it's run on OpenJ9 with -Xint. |
btw, I tried |
It seems to work fine with -Xjit:optlevel=cold or warm |
Running with |
I created a vlog file from a crashing run. Then I tried excluding the hot or higher methods one by one. By using the following as a limitfile, the testcase works. The following is what I disabled to get it working. |
Thanks @pshipton. I verified that with
not only do we not crash, but we also stop hanging. If I do
or if I do @0xdaryl given that this doesn't look like a control issue anymore and also since I'm only around tomorrow for a half day and on vacation all of next week, we should transfer this to someone who can take a look more actively. |
@a7ehuo : could you take over the investigation of this please? |
This is not a 0.33 regression. The hang is reproducible at least as far back as 0.24 on JDK11. |
I'm seeing different kinds of crashes including crash at (1) Core dump shows it crashed in As mentioned previously, I'm also seeing crash output shows one thing, the core shows it's in (2) Run test in gdb and got a crash in It crashed when it tries to get rom class for [1]
[2]
[3]
[4]
|
I'm still investigating. I saw the issue even with an older build back to January. Not sure if it should be a blocker now for the 0.33 release. Meanwhile, Most of the times, instead of a crash, now I'm seeing a hang which was also reported earlier. It seems stuck running [1]
[2]
|
With the following combination of -Xjit options, now I could sort of reliably reproduce the "Invalid JIT return address ..." failure.
The stack walk happened because of
|
We won't be able to get to the bottom of this for 0.35. Moving to 0.36. |
Moving to 0.38 release. |
No change on the status of this one. Moving out to 0.40. |
Verified the test with Java 8, 11, 17 release
|
Java -version output
Summary of problem
The given (unreduced)
Test.java
in following link crashes OpenJ9's JIT compiler.Should note that
So please be patient when triggerring this crash.
Please also check openj9-bug-69.tar.gz for all the logs (jitdump, coredump, output) and the test (Test.java, Test.class).
Diagnostic files
By issuing
the following crash log is given:
The text was updated successfully, but these errors were encountered: