JDK-8298851 : C2: ConvL2I nodes should not be split through phis
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17,18,19,20,21,22,23
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2022-12-15
  • Updated: 2024-05-03
  • Resolved: 2024-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23Resolved
Related Reports
Duplicate :  
JDK-8331575 - C2: crash when ConvL2I is split thru phi at LongCountedLoop
Relates :  
JDK-6663854 - assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp
Relates :  
JDK-8256655 - rework long counted loop handling
Relates :  
JDK-6659207 - access violation in CompilerThread0
Description
The attached Java Fuzzer test crashes because a ConvL2I node is split through a phi. The ConvL2I node is a TypeNode since JDK-8256655. In this case, a ConvL2I node has a the type range which is strictly positive and is a divisor of a Div node. As a result, the zero check is removed. When splitting the ConvL2I through a phi, it gets an input whose type includes zero. At runtime, that input is zero and we perform a division by zero and crash with SIGFPE. 

We should disallow PhaseIdealLoop::split_thru_phi(() for ConvL2I nodes as we are already disallowing ConvI2L nodes to be split through phis (JDK-6659207). We should also widen ConvL2I types in PhaseIdealLoop::split_up() similar to the widening done for ConvI2L nodes (JDK-6663854).

Reproduce:
$ java -Xcomp -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:CompileOnly=Reduced Reduced.java


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007f7e289ad285, pid=1806800, tid=1806801
#
# JRE version: Java(TM) SE Runtime Environment (20.0+28) (fastdebug build 20-ea+28-2221)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+28-2221, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# J 6 c2 Test.mainTest([Ljava/lang/String;)V (696 bytes) @ 0x00007f7e289ad285 [0x00007f7e289ac0c0+0x00000000000011c5]
..........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:CompileCommand=quiet -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/19/36/bundles/linux-x64/jdk-19_linux-x64_bin.tar.gz/jdk-19 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/91e16c40-06d4-468a-9fc3-7198a5bb7d5a-S17386/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d0a86b58-4275-4ebc-86d7-7b8ceb2956eb/runs/0e096938-ca3a-45a0-95d7-6674da96203a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_javafuzzer_BigTest_java/tmp Test
...........
Current thread (0x00007f7e3802b7d0):  JavaThread "main" [_thread_in_Java, id=1806801, stack(0x00007f7e40c94000,0x00007f7e40d95000)]

Stack: [0x00007f7e40c94000,0x00007f7e40d95000],  sp=0x00007f7e40d93890,  free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 6 c2 Test.mainTest([Ljava/lang/String;)V (696 bytes) @ 0x00007f7e289ad285 [0x00007f7e289ac0c0+0x00000000000011c5]
J 3 c1 Test.main([Ljava/lang/String;)V (45 bytes) @ 0x00007f7e20ee2e7c [0x00007f7e20ee2d20+0x000000000000015c]
v  ~StubRoutines::call_stub 0x00007f7e28419d21
V  [libjvm.so+0x1032070]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x500  (javaCalls.cpp:417)
V  [libjvm.so+0x1177949]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x389  (jni.cpp:887)
V  [libjvm.so+0x117adf5]  jni_CallStaticVoidMethod+0x1b5  (jni.cpp:1711)
C  [libjli.so+0x47d5]  JavaMain+0xd55  (java.c:547)
C  [libjli.so+0x7a29]  ThreadJavaMain+0x9  (java_md.c:650)

siginfo: si_signo: 8 (SIGFPE), si_code: 1 (FPE_INTDIV), si_addr: 0x00007f7e289ad285
Comments
Attached another Java Fuzzer crash which can be traced back to the same problem: $ java -XX:-TieredCompilation -Xcomp -XX:CompileOnly=Test3::* -XX:+StressGCM Test3.java
05-12-2023
Great, thank you!
27-11-2023
I've just verified that it is the same issue.
27-11-2023
java -Xmx1G -XX:+IgnoreUnrecognizedVMOptions -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test2*::* -XX:-TieredCompilation -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:MaxRAMPercentage=4.16667 Test2.java [~chagedorn], could you please check if it's the same issue?
27-11-2023
Applying the bailout fix for ConvL2I nodes in split_thru_phi() lets this reported test case by [~dcubed] pass. So, this indeed looks like a duplicated finding of this bug.
02-02-2023
Here's a log file snippet from he jdk-21+8-523-tier6 sighting: applications/javafuzzer/MediumTest.java Summary of the JavaFuzzer run: ------------------------------ Host: ol8-x64-525894 Tests: 12 x 50 Args: -conf config.yml Started at: Tue Jan 31 09:01:02 UTC 2023 r12- 50: 33 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 17 Reference Java failures r10- 50: 29 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 21 Reference Java failures r5- 50: 31 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 19 Reference Java failures r3- 50: 28 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 22 Reference Java failures r6- 50: 33 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 17 Reference Java failures r8- 50: 26 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 24 Reference Java failures r1- 50: 30 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 20 Reference Java failures r2- 50: 30 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 20 Reference Java failures r9- 50: 28 passed, 0 crashes, 1 fails, 0 hangs, 0 incorrect tests, 21 Reference Java failures r11- 50: 32 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 18 Reference Java failures r4- 50: 32 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 18 Reference Java failures r7- 50: 29 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 21 Reference Java failures Finished at: Tue Jan 31 10:37:36 UTC 2023 # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007f5ac90005c4, pid=3373736, tid=3373737 # # JRE version: Java(TM) SE Runtime Environment (21.0+8) (fastdebug build 21-ea+8-LTS-523) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+8-LTS-523, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 3 c2 Test.mainTest([Ljava/lang/String;)V (388 bytes) @ 0x00007f5ac90005c4 [0x00007f5ac9000200+0x00000000000003c4] # # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /tmp/fuzzer.tmp.rO641eMPhd/core.3373736) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # [2023-01-31T10:37:36.689857907Z] Waiting for completion for process 3330142 [2023-01-31T10:37:36.690047125Z] Waiting for completion finished for process 3330142 ----------System.err:(13/728)---------- java.lang.RuntimeException: assertEquals: expected 1 to equal 2 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at jdk.test.lib.Asserts.assertEquals(Asserts.java:189) at applications.javafuzzer.JavaFuzzerRunner.main(JavaFuzzerRunner.java:245) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1623) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: assertEquals: expected 1 to equal 2 Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x00007f5ad402bb60): JavaThread "main" [_thread_in_Java, id=3373737, stack(0x00007f5adc2cc000,0x00007f5adc3cd000)] Stack: [0x00007f5adc2cc000,0x00007f5adc3cd000], sp=0x00007f5adc3cb920, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 3 c2 Test.mainTest([Ljava/lang/String;)V (388 bytes) @ 0x00007f5ac90005c4 [0x00007f5ac9000200+0x00000000000003c4] J 2 c2 Test.main([Ljava/lang/String;)V (45 bytes) @ 0x00007f5ac9002d6c [0x00007f5ac9002cc0+0x00000000000000ac] v ~StubRoutines::call_stub 0x00007f5ac8ebed21 V [libjvm.so+0x1070450] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x500 (javaCalls.cpp:415) V [libjvm.so+0x11b60f9] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x389 (jni.cpp:887) V [libjvm.so+0x11b95d5] jni_CallStaticVoidMethod+0x1b5 (jni.cpp:1711) C [libjli.so+0x47d5] JavaMain+0xd55 (java.c:547) C [libjli.so+0x7a29] ThreadJavaMain+0x9 (java_md.c:650) siginfo: si_signo: 8 (SIGFPE), si_code: 1 (FPE_INTDIV), si_addr: 0x00007f5ac90005c4
01-02-2023
ILW = SIGFPE crash in C2 compiled code, single Java Fuzzer test, -XX:-SplitIfBlocks or disable compilation of affected methods = HLM = P3
15-12-2022