J9 (1.8.0_275-b01) crashed while J9 (9.0.4) and J9 (11.0.9+11) did not. #11683
Comments
|
Run the testcase against There was no crash and no core files generated. @fuzzy000 anything else required to reproduce the crash? |
|
@JasonFengJ9 On the original server (which can reproduce the crash): On the server that can not reproduce: Could you please try it on the same Ubuntu version? If you need any additional information, please feel free to let me know. Also, here inside the zip is the core.xxx.dmp, javacore.xxx.txt, jitdump.xxx.dmp and Snap.xxx.trc. I hope it useful for you. |
It was a crash at |
|
Pls try the 0.24 release milestone 2 builds in case this problem has already been resolved. |
|
@pshipton We also got a crash for the j9-8u282-b07 (0.24 release), here are the dump files: j9-8u282-dmp.zip We think this crash is possibly related to the server load. Our server that got those crashes was running lots of CPU tasks at the same time. |
|
@gacholio do you have cycles to look at the latest core? |
|
Reproduced locally on an internal build: Looks like the receiver to |
|
|
|
The only odd thing in the bytecodes is that the logger is called in between the creation of the NPE and the construction of it. There's also some junk code between the logger call and the constructor call. |
|
The failure I'm looking at occurs with -Xint. |
|
Running with |
|
Looking at the bytecodes above, this should fail bytecode verification. Bytecode 24 may branch to bytecode 64, bypassing any write to local 5 which is read at bytecode 65. The end result would be random data being passed up the NPE constructor chain eventually resulting in the garbage being read in the finalizer test in the object constructor. |
|
@ChengJin01 Any thoughts as to why this doesn't fail verification? It does not appear to be exempt: |
|
@gacholio , this is the same issue as #11684 and #11685 which was triggered by the fix at #9419 (explained at #11684 (comment)). The bytecode above was intentionally modified to trigger verification errors. I already created a new fix at ChengJin01@dbed590 to capture the verification error here against the same RI's behaviour at Will launch personal builds and verify the internal tests to ensure there is no break in the existing test suites. |
ChengJin01
pushed a commit
to ChengJin01/openj9
that referenced
this issue
Jan 22, 2021
The change is to reinforce the initial intention that only a target slot with BCV_SPECIAL_INIT is exempted from being set with top given setInitializedThisStatus() needs to check BCV_SPECIAL_INIT to flag the uninitialized_this object. Fixes: eclipse-openj9#11683,eclipse-openj9#11684,eclipse-openj9#11685 Signed-off-by: Cheng Jin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Java -version output
We used the following versions of J9:
Summary of problem
We made some changes to a class file in the JUnit project, and let several JVMs execute the corresponding JUnit test. We found that there are 6 classes caused the J9 (1.8.0_275-b01) to crash. For each crash, four files appears:
core.xxx.dmp,javacore.xxx.txt,jitdump.xxx.dmpandSnap.xxx.trc.Diagnostic files
j9-8-crash.zip
Steps to reproduce the behavior:
j9-8-crash.zipj9-8-crash, run commandcp Checks1.class sootOutput/junit-junit/org/junit/internal/Checks.class. You can also cp Checks2, Checks3, etc.java -cp sootOutput/junit-junit/:hamcrest-all-1.3.jar:junit-4.12.jar org.junit.runner.JUnitCore org.junit.internal.ChecksTestExecution environment
The text was updated successfully, but these errors were encountered: