C2 Compiler SIGSEGV in Matcher::xform compiling retryRelease0

XMLWordPrintable

    • x86_64
    • linux

      ADDITIONAL SYSTEM INFORMATION :
      JVM Version: OpenJDK 64-Bit Server VM Zulu25.30+17-CA (25.0.1+8-LTS, mixed mode, tiered, z gc, linux-amd64)
      Release: 25.0.1+8-LTS
      Vendor: Azul Zulu

      Relevant Global Flags at time of crash:
      UseCompressedClassPointers = false (command line, explicitly disabled)
      UseCompressedOops = false (ergonomic, automatically disabled by ZGC)
      UseZGC = true (command line)

      A DESCRIPTION OF THE PROBLEM :
      The JVM crashes with SIGSEGV during C2 compilation of io.netty.util.internal.ReferenceCountUpdater::retryRelease0.

      SIGSEGV happens @ V [libjvm.so+0xd5d60b] Matcher::xform(Node*, int)+0x5cb

      with the current compile task being:
      C2:321760874 25692 4 io.netty.util.internal.ReferenceCountUpdater::retryRelease0 (70 bytes)

      JVM: OpenJDK 64-Bit Server VM Zulu25.30+17-CA (25.0.1+8-LTS)

      JVM CONFIGURATION FOR THIS CRASH:
      - GC: ZGC (-XX:+UseZGC)
      - UseCompressedClassPointers = false (explicitly disabled via -XX:-UseCompressedClassPointers)
      - UseCompressedOops = false (ergonomic, automatically disabled by ZGC)

      This crash was discovered while attempting to work around another C2 crash in final_graph_reshaping_walk compiling the same retryRelease0 method (I've filed a separate issue for that). When we disabled compressed class pointers to avoid the other crash, we encountered this different crash instead. This suggests there might be multiple distinct C2 compilation bugs affecting the same method in Java 25.0.1.

      REPRODUCIBILITY:
      - Occurs reliably across multiple production services with Java 25.0.1
      - Time to reproduction varies by service: observed from less than an hour to several days
      - Consistently crashes when compiling the same method: io.netty.util.internal.ReferenceCountUpdater::retryRelease0
      - Observed with both ZGC and G1GC garbage collectors
      - Requires both UseCompressedClassPointers=false AND UseCompressedOops=false
      - Does NOT occur with default JVM settings (triggers the final_graph_reshaping_walk crash instead)

      Workaround: exclude retryRelease0 from compilation by specifying -XX:CompileCommand=exclude,io/netty/util/internal/ReferenceCountUpdater.retryRelease0


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Use Java 25.0.1 (we use Zulu25.30+17-CA but I suspect it might be reproducible on other builds of OpenJDK too)
      2. Configure JVM with ZGC (-XX:+UseZGC)
      3. Explicitly disable compressed class pointers: -XX:-UseCompressedClassPointers
      4. With ZGC, compressed oops will be automatically disabled (ergonomic setting)
      5. Include Netty networking library in application (io.netty:netty-all:4.2.7.Final)
      6. Run application with network I/O workload that exercises Netty's reference counting mechanisms
      7. Wait for C2 compiler to attempt problematic compilation of io.netty.util.internal.ReferenceCountUpdater::retryRelease0
      8. Crash occurs after service runtime varying from less than an hour to days depending on service

      I've provided the replay log in confidential data so that may be an easier way to reproduce.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      No crash
      ACTUAL -
      Crash

      ---------- BEGIN SOURCE ----------
      The crash occurs when compiling a method from the public Netty library:

      Library: io.netty:netty-all:4.2.7.Final (includes netty-common where this class resides)
      Class: io.netty.util.internal.ReferenceCountUpdater (abstract class)
      Method: retryRelease0 (private method, 70 bytes of bytecode)
      ---------- END SOURCE ----------

            Assignee:
            Unassigned
            Reporter:
            Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: