I hope you can check whether this is a ZGC-related bug.
Version: openjdk-23-ga
Git command: git clone --branch jdk-23-ga https://github.com/openjdk/jdk.git
In one run, I caused the VM to halt and the following message appeared:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007c928eaf58da, pid=214039, tid=214049
#
# JRE version: OpenJDK Runtime Environment (23.0) (build
23-internal-adhoc.yifanzhang.jdk)
# Java VM: OpenJDK 64-Bit Server VM (23-internal-adhoc.yifanzhang.jdk,
interpreted mode, sharing, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x10f58da]
ZRelocationSetSelectorGroup::semi_sort()+0x13a
#
# No core dump will be written. Core dumps have been disabled. To
enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
#
/home/yifanzhang/Work/Bug-HotspotVM/testFile/JavaFile/Gjf_Case22/hs_err_pid214039.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
#
已中止
I looked into the VM source code and found that this appears to be an array
out-of-bounds error.
Detailed problem description :
In function `ZRelocationSetSelectorGroup::semi_sort()` , an array
partitions[npartitions] is allocated. Under the heap’s default settings,
its size is 2048 (meaning indices 0 through 2047 are valid).
However, the subsequent index used for access is determined by
right-shifting each page’s live byte count, which may lead to accessing
index 2048.
Based on this, I made the following changes to the function
`semi_sort()`, add a conditional branch to print corresponding information
when an out-of-bounds access may occur. :
```
int partitions[npartitions] = { /* zero initialize */ };
// Calculate partition slots
ZArrayIterator<ZPage*> iter1(&_live_pages);
for (ZPage* page; iter1.next(&page);) {
const size_t index = page->live_bytes() >> partition_size_shift;
if (index >= npartitions) {
log_info(gc,
heap)("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
log_info(gc, heap)("Size of partition array : %zu", npartitions);
log_info(gc, heap)("partition_size = _page_size >>
npartitions_shift : %zu = %zu >> %zu", partition_size, _page_size,
npartitions_shift);
log_info(gc, heap)("partition_size_shift =
exact_log2(partition_size) : %zu", partition_size_shift);
log_info(gc, heap)("Index will be visited (page->live_bytes() >>
partition_size_shift): %zu", index);
log_info(gc, heap)("Page lived bytes: %zu", page->live_bytes());
log_info(gc,
heap)("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
}
partitions[index]++;
}
```
Here is the information I obtained:
[4.779s][info][gc,heap]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[4.779s][info][gc,heap] Size of partition array : 2048
[4.779s][info][gc,heap] partition_size = _page_size >> npartitions_shift :
1024 = 2097152 >> 11
[4.779s][info][gc,heap] partition_size_shift = exact_log2(partition_size) :
10
[4.779s][info][gc,heap] Index will be visited (page->live_bytes() >>
partition_size_shift): 2048
[4.779s][info][gc,heap] Page lived bytes: 2097152
[4.779s][info][gc,heap]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
So I’d like to ask you to check whether this is a related bug, and
if so, whether I should open a corresponding issue in the JDK bug system.