Hi, It looks like you have found a bug. Feel free to create a new Bug report in the JDK bug system. If you don't have access to JBS, we can open a bug for you. Thanks! StefanK On 2025-12-06 08:16, yifan zhang wrote:
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.