ZGC Related Developers,

[Stefan Karlsson]

Hi again,

Could you tell us what JVM flags you are using when you are hitting this 
issue?

We're also curious if you have your own set of patches on top of the 
code openjdk/jdk?

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