Assertion Failure at ScavengerDelegate.cpp:392
connglli opened this issue · 5 comments
connglli commented
Java -version output
openjdk version "17.0.4-internal" 2022-07-19
OpenJDK Runtime Environment (build 17.0.4-internal+0-adhoc..openj9-openjdk-jdk17)
Eclipse OpenJ9 VM (build master-79f0b73fa, JRE 17 Linux amd64-64-Bit Compressed References 20220701_000000 (JIT enabled, AOT enabled)
OpenJ9 - 79f0b73fa
OMR - d018241d7
JCL - c6e2f71170b based on jdk-17.0.4+7)
Summary of problem
The following triggers an assertion failure in ScavengerDelegate.cpp. Also a JIT bug (cannot reproduce with Xint).
class Test {
long lFld;
double dFld;
void vMeth1(short s) {
int ax$2 = 0x26cb6487;
byte[] ax$1 = new byte[ax$2];
int ax$4 = ax$1.length;
for (int k = 0; ax$4 > 0; ax$4--) {
int ax$3 = ax$1.length - ax$4;
ax$1[ax$3] = (byte) 0xff;
}
}
void vMeth(long l, int i1, float f) {
short s2 = 23847;
try {
for (int ax$6; ; ) vMeth1((short) 1189680613);
} catch (Throwable ax$7) {
} finally {
}
vMeth1(s2);
}
void mainTest(String[] strArr1) {
int i = 26;
vMeth(lFld, i, 1.750F);
}
public static void main(String[] strArr) {
Test _instance = new Test();
_instance.mainTest(strArr);
}
}Diagnostic files
By issuing
$ java -Xmx1G -Xshareclasses:none Test
the following crash log is given:
Bad scan type for object pointer 00000000E6CEF1B0
Bad scan type for object pointer 00000000E6CE9B70
11:18:29.134 0x1d6400 j9mm.141 * ** ASSERTION FAILED ** at /root/hostdir/openj9-openjdk-jdk17/openj9/runtime/gc_glue_java/ScavengerDelegate.cpp:392: ((false))
11:18:29.134 0x1b0800 j9mm.141 * ** ASSERTION FAILED ** at /root/hostdir/openj9-openjdk-jdk17/openj9/runtime/gc_glue_java/ScavengerDelegate.cpp:392: ((false))
JVMDUMP039I Processing dump event "traceassert", detail "" at 2022/07/20 13:18:29 - please wait.
JVMDUMP039I Processing dump event "traceassert", detail "" at 2022/07/20 13:18:29 - please wait.
JVMDUMP032I JVM requested System dump using '/zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/core.20220720.131829.1701819.0001.dmp' in response to an event
JVMDUMP010I System dump written to /zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/core.20220720.131829.1701819.0001.dmp
JVMDUMP032I JVM requested Java dump using '/zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/javacore.20220720.131829.1701819.0003.txt' in response to an event
JVMDUMP032I JVM requested System dump using '/zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/core.20220720.131829.1701819.0002.dmp' in response to an event
JVMDUMP012E Error in Java dump: /zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/javacore.20220720.131829.1701819.0003.txt
JVMDUMP010I System dump written to /zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/core.20220720.131829.1701819.0002.dmp
JVMDUMP032I JVM requested Java dump using '/zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/javacore.20220720.131829.1701819.0005.txt' in response to an event
JVMDUMP032I JVM requested Snap dump using '/zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/Snap.20220720.131829.1701819.0004.trc' in response to an event
JVMDUMP010I Snap dump written to /zdata/congli/ax-exp/ax-eval/2-ax-only/111.openj9/mutant/red/Snap.20220720.131829.1701819.0004.trc
JVMDUMP013I Processed dump event "traceassert", detail "".
Please also check openj9-bug-111.tar.gz for all the logs (core, snap, etc.), the reduced test (Test.java, Test.class), and unreduced (Test.java.orig, FuzzerUtils.java).
dmitripivkine commented
object heap corruption:
Bad scan type for object pointer 00000000E6CEF1B0
Bad scan type for object pointer 00000000E6CE9B70
0xE6CE9B20 : 00000000 00000000 00000000 00000000 [ ................ ]
0xE6CE9B30 : 00000000 00000000 00000000 00000000 [ ................ ]
0xE6CE9B40 : 00000000 ffff0000 ffffffff ffffffff [ ................ ]
0xE6CE9B50 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CE9B60 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CE9B70 : ffffffff ffffffff ffffffff ffffffff [ ................ ]<---
0xE6CE9B80 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
......
0xE6CEF180 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CEF190 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CEF1A0 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CEF1B0 : ffffffff ffffffff ffffffff ffffffff [ ................ ]<---
0xE6CEF1C0 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
0xE6CEF1D0 : ffffffff ffffffff ffffffff ffffffff [ ................ ]
The pattern reminds me #15474
connglli commented
@dmitripivkine I created a new issue in #15592 that is also similar to this one and #15474. Don't know if they three stem from the same root cause (because the tests are so similar to each other) but they indeed gives different crashes.