Assertion Failure at ScavengerDelegate.cpp:392

[connglli]

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).

[pshipton]

@0xdaryl fyi

[dmitripivkine]

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]

@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.

[hzongaro]

Duplicate of #15474

[hzongaro]

Fixed by pull request #15870.