Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8349139

C2: SIGFPE with modified test from JDK-8263971 TestLostDependencyOnZeroTripGuard.java

XMLWordPrintable

      I found this during work on JDK-8340093.

      I took the test added by JDK-8263971: TestLostDependencyOnZeroTripGuard.java
      And only changed the limit 3 -> 2.
      https://github.com/openjdk/jdk/pull/3190

      It could be a JDK24 regression of JDK-8334724, was the initial guess by [~chagedorn].
      https://github.com/openjdk/jdk/pull/19831

      -------------------- How to Reproduce ---------------------

      On latest JDK24 or JDK25 (did not reproduce on JDK23).

      /oracle-work/jdk-25/fastdebug/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test::* -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:UseAVX=2 -XX:StressSeed=139899009 -XX:CompileCommand=printassembly,*::mainTest Test.java

      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # SIGFPE (0x8) at pc=0x00007ff0009728af, pid=273793, tid=273794
      #
      # JRE version: Java(TM) SE Runtime Environment (25.0+8) (fastdebug build 25-ea+8-LTS-843)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-ea+8-LTS-843, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
      # Problematic frame:
      # J 88 c2 Test.mainTest([Ljava/lang/String;)V (115 bytes) @ 0x00007ff0009728af [0x00007ff000972760+0x000000000000014f]
      #
      # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork5/core.273793)
      #
      # An error report file with more information is saved as:
      # /oracle-work/jdk-fork5/hs_err_pid273793.log
      #
      # If you would like to submit a bug report, please visit:
      # https://bugreport.java.com/bugreport/crash.jsp
      #
      Aborted (core dumped)


      From my first assessment, it looks exactly like the bug from:
      https://github.com/openjdk/jdk/pull/3190

      A DivI sits in the main-loop. But that main-loop eventually is fully unrolled, and loses its loop structure. Before this, the DivI had to be scheduled after the loop-phi of the main-loop. But after the loop structure removal, the DivI can float up, even inside the pre-loop with StressGCM.

      https://github.com/openjdk/jdk/pull/3190
      Should have fixed this with the CastII.

      But then the CastII was removed again by:
      https://github.com/openjdk/jdk/pull/19831
      (needs to be confirmed, this is only speculation at this point)

            roland Roland Westrelin
            epeter Emanuel Peter
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: