SIGSEGV (0xb) at pc=0x00007f4b60b5f5c9, pid=[PID], tid=[TID]

XMLWordPrintable

    • gc
    • linux

      ADDITIONAL SYSTEM INFORMATION :
      Property settings:
          awt.toolkit = sun.awt.X11.XToolkit
          file.encoding = UTF-8
          file.encoding.pkg = sun.io
          file.separator = /
          java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
          java.awt.printerjob = sun.print.PSPrinterJob
          java.class.path = .
          java.class.version = 52.0
          java.endorsed.dirs = /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/endorsed
          java.ext.dirs = /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/ext
              /usr/java/packages/lib/ext
          java.home = /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre
          java.io.tmpdir = /tmp
          java.library.path = /usr/java/packages/lib/amd64
              /usr/lib64
              /lib64
              /lib
              /usr/lib
          java.runtime.name = OpenJDK Runtime Environment
          java.runtime.version = 1.8.0_472-b08
          java.specification.maintenance.version = 6
          java.specification.name = Java Platform API Specification
          java.specification.vendor = Oracle Corporation
          java.specification.version = 1.8
          java.vendor = Temurin
          java.vendor.url = https://adoptium.net/
          java.vendor.url.bug = https://github.com/adoptium/adoptium-support/issues
          java.version = 1.8.0_472
          java.vm.info = mixed mode
          java.vm.name = OpenJDK 64-Bit Server VM
          java.vm.specification.name = Java Virtual Machine Specification
          java.vm.specification.vendor = Oracle Corporation
          java.vm.specification.version = 1.8
          java.vm.vendor = Temurin
          java.vm.version = 25.472-b08
          line.separator = \n
          os.arch = amd64
          os.name = Linux
          os.version = 4.15.0-196-generic
          path.separator = :
          sun.arch.data.model = 64
          sun.boot.class.path = /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/resources.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/rt.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/sunrsasign.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/jsse.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/jce.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/charsets.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/jfr.jar
              /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/classes
          sun.boot.library.path = /usr/lib/jvm/java-8-openjdk-new/jdk8u472-b08/jre/lib/amd64
          sun.cpu.endian = little
          sun.cpu.isalist =
          sun.io.unicode.encoding = UnicodeLittle
          sun.java.launcher = SUN_STANDARD
          sun.jnu.encoding = UTF-8
          sun.management.compiler = HotSpot 64-Bit Tiered Compilers
          sun.os.patch.level = unknown
          user.dir = [EDITED]
          user.home = /root
          user.language = en
          user.name = root
          user.timezone =

      openjdk version "1.8.0_472"
      OpenJDK Runtime Environment (Temurin)(build 1.8.0_472-b08)
      OpenJDK 64-Bit Server VM (Temurin)(build 25.472-b08, mixed mode)


      A DESCRIPTION OF THE PROBLEM :
      Operating System: Ubuntu 20.04.6 LTS (Linux 4.15.0-196-generic, amd64)
      CPU: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz
      40 total logical processors (2 sockets × 10 cores × 2 threads)
      Family 6, Model 79, Stepping 1
      JRE Version: OpenJDK Runtime Environment (8.0_472-b08)
      (build 1.8.0_472-b08)
      Java VM: OpenJDK 64-Bit Server VM (25.472-b08, mixed mode, linux-amd64, compressed oops)
      Heap Configuration: G1 Garbage Collector, 32 MB heap (-Xmx32m -Xms32m)
      Special JVM Flags:
      text


      -XX:+UseG1GC
      -XX:+UnlockExperimentalVMOptions
      -XX:+UnlockDiagnosticVMOptions
      -XX:G1ReservePercent=108845
      -XX:G1ConcRefinementYellowZone=223946
      -XX:G1RSetSparseRegionEntries=521832
      Java Agent: Custom agent loaded via -javaagent:[EDITED]/Schedule-1.0-SNAPSHOT-agent.jar
      Issue Description:
      The JVM crashed with a SIGSEGV (segmentation fault) during garbage collection. The crash occurred in the VMThread, which is responsible for internal JVM operations such as safepoint synchronization and GC pauses. The problematic frame is inside libjvm.so at symbol:
      RegisterHumongousWithInCSetFastTestClosure::doHeapRegion(HeapRegion*)
      This indicates a bug in the G1 garbage collector’s handling of humongous objects during an incremental collection pause (G1IncCollectionPause). The use of extremely large diagnostic/experimental flags (e.g., G1ReservePercent=108845%) may have exposed an edge-case memory corruption or invalid pointer dereference in the remembered set or humongous region registration logic.
      Error Details:
      Signal: SIGSEGV (11)
      Signal Code: SEGV_MAPERR (1) — attempted to access unmapped memory
      Faulting Address: 0x00007f4b645d6258
      Program Counter (PC): 0x00007f4b60b5f5c9
      Problematic Frame:
      V [libjvm.so+0x5a75c9] RegisterHumongousWithInCSetFastTestClosure::doHeapRegion(HeapRegion*)+0x199
      Thread Context:
      Crashing Thread: VMThread (native thread ID 20680, Java thread pointer 0x00007f4b5c173000)
      VM Operation: G1IncCollectionPause (requested by Java thread pool-1-thread-1)
      VM State: at safepoint (normal execution)
      Held Locks:
      Threads_lock — owned by VMThread
      Heap_lock — owned by pool-1-thread-1 (application thread that triggered GC)
      This confirms the crash happened entirely within JVM native GC code, not in Java application code.
      Supporting Evidence from Log:
      Heap Size: Only 32 MB, yet contains multiple humongous objects (regions marked HS/HC)
      GC Activity: Frequent young GCs; crash occurs during registration of humongous regions into the collection set fast-test structure
      Core Dump: Written to [EDITED]/core or core.20613
      Agent Involvement: The test uses a custom Java agent to replay a specific allocation/GC sequence, which is necessary to trigger this rare state


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Steps to Reproduce:

      1. Clone the reproduction repository:
         $ git clone [EDITED]
         $ cd BugReport

      2. Extract the reproduction case (if compressed):
         $ unzip GCtestcase-4.zip

      3. Compile and Run the reproduction script:

         Before running the script, please edit execution.properties and update the jvm and javac paths to point to your local installation.

         $ bash ./scripts/replay.sh -s sequence.json -t com/gcscheduling/generated/ConcurrentTest_20260110_070655_785.java -p vmoption.vmopts


      ---------- BEGIN SOURCE ----------
      [EDITED]

      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Reproducing this issue requires a custom Java agent (provided as a .jar file) that instruments class loading and garbage collection behavior in a specific way. This agent is essential to trigger the exact sequence of events leading to the crash.
      To ensure the reproduction environment is complete and self-contained, we have packaged:
      The Java agent JAR,
      The generated test class,
      The JVM options (vmopts),
      And the execution script,
      into a single archive (GCtestcase-1.zip) hosted in a public GitHub repository.


      FREQUENCY :
      OFTEN

            Assignee:
            Mario Cadiz Olivares
            Reporter:
            Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: