ZGC Related Developers,

[yifan zhang]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20251206/572d198b/attachment-0001.htm>