System.Logger Triggers J9 Crash on OpenJDK 17 and 21

[yingquanzhao]

Java -version output

openjdk version "17.0.14" 2025-01-21
IBM Semeru Runtime Open Edition 17.0.14.0 (build 17.0.14+7)
Eclipse OpenJ9 VM 17.0.14.0 (build openj9-0.49.0, JRE 17 Linux amd64-64-Bit Compressed References 20250121_961 (JIT enabled, AOT enabled)
OpenJ9   - 3c3d179854
OMR      - e49875871
JCL      - cbbc8b94a62 based on jdk-17.0.14+7)

openjdk version "21.0.6" 2025-01-21 LTS
IBM Semeru Runtime Open Edition 21.0.6.0 (build 21.0.6+7-LTS)
Eclipse OpenJ9 VM 21.0.6.0 (build openj9-0.49.0, JRE 21 Linux amd64-64-Bit Compressed References 20250121_380 (JIT enabled, AOT enabled)
OpenJ9   - 3c3d179854
OMR      - e49875871
JCL      - e01368f00df based on jdk-21.0.6+7)

Output from java -version.

Summary of problem

Hi, we have found a test program that causes OpenJ9 to crash. Below is the minimized version of the test program:

public class Test {

    public static long var1 = 1871533038L;
    public double var2 = 1;
    public int var3 = 1;

    public void mainTest(String[] strArr1) {
        
        for (int i = 1; i < 5; i++) {

            System.Logger logger = System.getLogger(Test.class.getName());
            logger.log(System.Logger.Level.INFO, "Logging example");
            try {
                java.lang.reflect.Method method = Test.class.getMethod("mainTest", String[].class);
                method.invoke(this, (Object) strArr1);
            } catch (NoSuchMethodException e) {
                // ...
            } catch (IllegalAccessException e) {
                // ...
            } catch (java.lang.reflect.InvocationTargetException e) {
                // ...
            }
        }
        System.out.println("Value: " + Test.var1 + "," + Double.doubleToLongBits(var2) + "," + var3);
    }

    public static void main(String[] strArr) {
        new Test().mainTest(strArr);
    }
}

When compiled and executed this test program using OpenJDK 17 and OpenJDK 21, OpenJ9 crashes after running for approximately one minute. However, the issue does not occur when using OpenJDK 11 or other JVM implementations (such as HotSpot).
The core dump file generated from the crash can be downloaded from CoreDumpFile.zip.

Steps to Reproduce

1. Compile test program:
>>> javac Test.java

2. Excute test program:
>>> pathToOpenJ9/jdk-17.0.14+7-jre/bin/java -cp . Test
>>> pathToOpenJ9/jdk-21.0.6+7/bin/java -cp . Test

We have tested on both macOS and Ubuntu, and the crash can be triggered on both platforms.

We would appreciate it if you could take a look at this issue. Thank you!

Test Environment

macOS version:

Software:

    System Software Overview:
      System Version: macOS 13.2 (22D49)
      Kernel Version: Darwin 22.3.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: MacBook Pro
      User Name: MacBook
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 1 day, 2 hours, 19 minutes

Hardware:
    Hardware Overview:
      Model Name: MacBook Pro
      Model Identifier: MacBookPro18,1
      Model Number: MK193CH/A
      Chip: Apple M1 Pro
      Total Number of Cores: 10 (8 performance and 2 efficiency)
      Memory: 16 GB
      System Firmware Version: 8419.80.7
      OS Loader Version: 8419.80.7
      Activation Lock Status: Disabled

ubuntu version:

OS:
    lsb_release -a output:		
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04.6 LTS
    Release:        20.04
    Codename:       focal

Diagnostic files

The core dump file can be found in the attachment.

[hangshao0]

Assertion failure in JIT.

Assertion failed at /root/CCM/JDK21/openj9-openjdk-jdk21/omr/compiler/compile/OMRSymbolReferenceTable.cpp:1814: !owningMethodSymbol->comp()->getOption(TR_EnableOSR) || (slot + TR::Symbol::convertTypeToNumberOfSlots(type) - 1) < owningMethodSymbol->getNumPPSlots()
VMState: 0x00050080
        cannot create a pending push temporary that exceeds the number of slots for this method

compiling Test.mainTest([Ljava/lang/String;)V at level: very-hot (profiling)

FYI @hzongaro

[hzongaro]

@matthewhall2, may I ask you to take a look at this? It seems to be crashing during IL generation on string concatenation operations.

@nbhuiyan, FYI.

[matthewhall2]

The issue appears to be caused by a stack overflow when resolving the invokedynamic callsite. All Throwables are caught in MethodHandleResolver.resolveInvokeDynamic(), but we do not check for a stack overflow. This overflow is expected given the recursion with no guaranteed base case in this test case.

The reason this causes an issue is that even though no valid target is returned from MethodHandleNatives.linkCallSite, we still return a method like
java/lang/invoke/LambdaForm$MH/0x00000000e0164ba0.invoke(Ljava/lang/Object;)Ljava/lang/Object;
which has the wrong signature. In the test case above we are expecting something similiar to
java/lang/invoke/LambdaForm$MH/<some anonymous class>.linkToTargetMethod(JJILjava/lang/Object;) or
java/lang/invoke/MethodHandle.linkToStatic(JJILjava/lang/Object;Ljava/lang/Object;)Ljava/lang/String;

Then in ILGen, even though we have the wrong signature - a method with 1 argument - we have still put 3 values into operand stack slots. These should be popped off after generating IL for the invokedynamic call, but since we have the incorrect number of arguments, they are not.
After that, we add the return value to the operand stack. However since no args were popped off, we go beyond the maximum number of slots. Finally we enter OSR BookKeeping, and try to find a pending push temp slot for everything on the stack. But since we are already over the maximum, we get the cannot create a pending push temporary that exceeds the number of slots for this method assertion error.

PR for fix is linked above.

[jdmpapin]

Here's a minimal repro that allows us to see this situation play out with different types of exception: 21419-repro.zip

Use the class file rather than recompiling the Java source. I've modified it to replace the bootstrap method for the invokedynamic. For the concatenation as generated by javac, the bootstrap method is java/lang/invoke/StringConcatFactory.makeConcatWithConstants(), but as the comment says, I've changed it to Foo.bootstrap(). So it will throw the exception type specified by -DTHROWABLE_CLASS=... the first time we resolve, but if we try to resolve again, it will simply forward to StringConcatFactory.makeConcatWithConstants().

This is compiled for JDK17. Running in the interpreter, we can see that the behaviour for invokedynamic resolution failure is like any other resolution failure. We rethrow the exception and do not attempt to resolve again (or there would be a second "bootstrap" line):

$ java -DTHROWABLE_CLASS=java.lang.StackOverflowError -Xint Foo
bootstrap
java.lang.BootstrapMethodError: java.lang.StackOverflowError
java.lang.BootstrapMethodError: java.lang.StackOverflowError

The same thing happens with different exception types, e.g. java.lang.AssertionError or even a custom exception type like this:

public class CustomException extends Exception {}

Allowing the resolution to happen in the interpreter in the first call and then compiling for the second call, we can reproduce the pending push temporary assertion:

$ TR_EnableStartupNextGenHCRAtAllOpts=1 java -DTHROWABLE_CLASS=java.lang.StackOverflowError -Xjit:'limit=go,count=1,disableAsyncCompilation,initialOptLevel=warm,disableGuardedCountingRecompilation' Foo
...
Assertion failed at /home/jdmpapin/code/build-ojdk/openj9-openjdk-jdk17/omr/compiler/compile/OMRSymbolReferenceTable.cpp:1913: !owningMethodSymbol->comp()->getOption(TR_EnableOSR) || (slot + TR::Symbol::convertTypeToNumberOfSlots(type) - 1) < owningMethodSymbol->getNumPPSlots()
VMState: 0x00050080
        cannot create a pending push temporary that exceeds the number of slots for this method
...

This also happens regardless of the exception type. (And it happens even though the invokedynamic is taking only one int argument.)

Applying #21720 prevents the crash, but only for StackOverflowError. If we throw any other type of exception instead, it still fails the assertion. Additionally, in the case of StackOverflowError, it causes us to retry the resolution, which I think we aren't supposed to do:

$ java -DTHROWABLE_CLASS=java.lang.StackOverflowError -Xint Foo
bootstrap
java.lang.StackOverflowError
bootstrap
x=42

[jdmpapin]

Applying #21720 prevents the crash, but only for StackOverflowError. [...]

Just a few minutes ago, #21720 was updated based on the above (since @matthewhall2 was already aware of it). My statement was about the original change in that PR, not the new one.