-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P3
-
None
-
Affects Version/s: 8u481
-
Component/s: hotspot
-
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 logical cores (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:
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:+UnlockDiagnosticVMOptions
-XX:G1RSetSparseRegionEntries=47507
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 an incremental garbage collection pause. The crash occurred in the VMThread, which executes internal JVM operations such as GC maintenance tasks at safepoints.
The problematic frame is located in native JVM code within libjvm.so at the symbol:
RSHashTableIter::has_next(unsigned long&)+0x2db
This function is part of the Remembered Set (RSet) hash table iteration logic in the G1 garbage collector. The crash happened while the GC was attempting to register humongous regions with the in-collection-set fast test structure, as indicated by the call stack:
text
编辑
V [libjvm.so+0xa58dcb] RSHashTableIter::has_next(unsigned long&)+0x2db
V [libjvm.so+0x638fe1] HeapRegionRemSetIterator::has_next(unsigned long&)+0x31
V [libjvm.so+0x5a7597] RegisterHumongousWithInCSetFastTestClosure::doHeapRegion(HeapRegion*)+0x167
...
V [libjvm.so+0x5a4283] G1CollectedHeap::do_collection_pause_at_safepoint(double)+0x4e3
The use of a very small heap (32 MB) combined with humongous object allocation and non-standard diagnostic tuning (G1RSetSparseRegionEntries=47507) likely exposed a memory safety issue—possibly an invalid pointer dereference or buffer overrun—during RSet traversal.
Error Details:
Signal: SIGSEGV (11)
Signal Code: SEGV_ACCERR (2) — invalid permissions for attempted memory access
Faulting Address: 0x00007f753ffd3010
Program Counter (PC): 0x00007f76605c8dcb
Problematic Frame:
V [libjvm.so+0xa58dcb] RSHashTableIter::has_next(unsigned long&)+0x2db
Thread & VM Context:
Crashing Thread: VMThread (native thread ID 23844)
VM Operation: G1IncCollectionPause (triggered by Java thread pool-1-thread-1)
VM State: at safepoint (normal execution)
Held Locks:
Threads_lock — owned by VMThread
Heap_lock — owned by application thread pool-1-thread-1
This confirms the crash occurred deep within JVM native GC code, not in Java application logic.
Supporting Observations:
The heap contains multiple humongous objects (regions marked HS/HC), which stress the RSet infrastructure.
A custom Java agent is used to replay a specific allocation/GC sequence that reliably triggers this crash.
Core dump was written to [EDITED]/core or core.23777.
Conclusion:
This is a JVM internal crash in the G1 garbage collector’s Remembered Set iteration logic, likely triggered by edge-case interactions between humongous objects, sparse RSet configuration, and a constrained heap size. The issue is reproducible using the provided agent and test sequence.
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-5.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_061438_518.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-5.zip) hosted in a public GitHub repository.
FREQUENCY :
OFTEN
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 logical cores (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:
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:+UnlockDiagnosticVMOptions
-XX:G1RSetSparseRegionEntries=47507
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 an incremental garbage collection pause. The crash occurred in the VMThread, which executes internal JVM operations such as GC maintenance tasks at safepoints.
The problematic frame is located in native JVM code within libjvm.so at the symbol:
RSHashTableIter::has_next(unsigned long&)+0x2db
This function is part of the Remembered Set (RSet) hash table iteration logic in the G1 garbage collector. The crash happened while the GC was attempting to register humongous regions with the in-collection-set fast test structure, as indicated by the call stack:
text
编辑
V [libjvm.so+0xa58dcb] RSHashTableIter::has_next(unsigned long&)+0x2db
V [libjvm.so+0x638fe1] HeapRegionRemSetIterator::has_next(unsigned long&)+0x31
V [libjvm.so+0x5a7597] RegisterHumongousWithInCSetFastTestClosure::doHeapRegion(HeapRegion*)+0x167
...
V [libjvm.so+0x5a4283] G1CollectedHeap::do_collection_pause_at_safepoint(double)+0x4e3
The use of a very small heap (32 MB) combined with humongous object allocation and non-standard diagnostic tuning (G1RSetSparseRegionEntries=47507) likely exposed a memory safety issue—possibly an invalid pointer dereference or buffer overrun—during RSet traversal.
Error Details:
Signal: SIGSEGV (11)
Signal Code: SEGV_ACCERR (2) — invalid permissions for attempted memory access
Faulting Address: 0x00007f753ffd3010
Program Counter (PC): 0x00007f76605c8dcb
Problematic Frame:
V [libjvm.so+0xa58dcb] RSHashTableIter::has_next(unsigned long&)+0x2db
Thread & VM Context:
Crashing Thread: VMThread (native thread ID 23844)
VM Operation: G1IncCollectionPause (triggered by Java thread pool-1-thread-1)
VM State: at safepoint (normal execution)
Held Locks:
Threads_lock — owned by VMThread
Heap_lock — owned by application thread pool-1-thread-1
This confirms the crash occurred deep within JVM native GC code, not in Java application logic.
Supporting Observations:
The heap contains multiple humongous objects (regions marked HS/HC), which stress the RSet infrastructure.
A custom Java agent is used to replay a specific allocation/GC sequence that reliably triggers this crash.
Core dump was written to [EDITED]/core or core.23777.
Conclusion:
This is a JVM internal crash in the G1 garbage collector’s Remembered Set iteration logic, likely triggered by edge-case interactions between humongous objects, sparse RSet configuration, and a constrained heap size. The issue is reproducible using the provided agent and test sequence.
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-5.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_061438_518.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-5.zip) hosted in a public GitHub repository.
FREQUENCY :
OFTEN