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 :
OS: Linux (amd64)
JRE Version: OpenJDK Runtime Environment (8.0_452-b09)
(build 1.8.0_452-8u452-ga～us1-0ubuntu1～20.04-b09)
Java VM: OpenJDK 64-Bit Server VM (25.452-b09, mixed mode, linux-amd64, compressed oops)
CPU Architecture: linux-amd64 (exact CPU model not logged, but system is 64-bit x86)
Heap Configuration: G1 Garbage Collector, 256 MB heap
(garbage-first heap total 262144K)
Issue Description:
The JVM terminated abruptly with a SIGSEGV (segmentation fault). The crash occurred in the VMThread, which handles internal JVM operations such as garbage collection. The problematic frame is within libjvm.so, and the VM operation at the time of crash was G1IncCollectionPause, indicating this happened during an incremental G1 garbage collection cycle. This points to a bug in the JVM’s G1 GC implementation—potentially related to Remembered Set (RSet) processing, humongous object handling, or concurrent marking data structures.
Error Details:
Signal: SIGSEGV (0xb)
Signal Code: SEGV_MAPERR (0x1) — invalid memory address (not mapped)
Faulting Address: 0x000000000000013f (a very low, likely null-derived address)
Program Counter (PC): 0x00007f20056e9839
Problematic Frame:
V [libjvm.so+0x5a5839]
Note: The exact C++ symbol (e.g., function name) is not available in the log due to missing debug symbols, but the offset 0x5a5839 in libjvm.so corresponds to code executed during G1 remembered set iteration or card table scanning.
Thread Context:
Crashing Thread: VMThread
Native thread ID: 720
Stack range: [0x00007f1ee4070000, 0x00007f1ee4170000]
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 (the application thread that triggered GC)
This confirms the crash occurred deep within JVM native GC code, not in Java application logic.
Supporting Evidence from Log:
GC Type: G1 Garbage Collector
Heap Usage at Crash: ～100,308 KB used out of 262,144 KB (≈38% full)
Humongous Objects: Multiple regions marked as HS (Humongous Starts) and HC (Humongous Continues), suggesting large object allocation may be a contributing factor.
Metaspace Usage: 8,012 KB used
Core Dump: Written to [EDITED]/core or core.651

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

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

2. Extract the reproduction case (if compressed):
   $ unzip GCtestcase-3.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_070449_636.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