RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang [v5]

[Kevin Walls]

On Tue, 16 Sep 2025 08:22:10 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - nn
>  - comment and rename

Thanks for the additional info.

If I ignore what's said so far and start again, I see the following...  (anyone should feel free to correct, we aren't in this area every day!...)

hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)

          print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
                        target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);

core has no mapping at exactly 0x7fa9ff0e4440 but has:

  Start                 End               Page Offset
  0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
  0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
  

The error is having a size 0x17c30 mapping that should go at 0x00007fa9ff0e4000
That is the second LOAD phdr from libjimage.

The check which has been working for gcc builds:
ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)

102400 	= 0x19000 is mem size, page size aligned. The core has a mapping of this size.
97328	= 0x17c30 libjimage has this, which rounds up to only 0x18000

libjimage is providing too little data? 
But target vaddr 0x7fa9ff0e4440 is offset into the actual segment 0x00007fa9ff0e4000 by  0x440  (1088 bytes)

0x17c30 + 0x440 = 0x18070 which rounds up to the wanted 0x19000


src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c

399       uintptr_t target_vaddr = lib_php->p_vaddr + lib_base;
400       map_info *existing_map = core_lookup(ph, target_vaddr);

(Existing code expects target_vaddr and existing_map->vaddr to be exactly equal, not to see target_vaddr being anything other than 0x1000 aligned.)

Maybe we:
check if target_vaddr > existing_map->vaddr and add any difference to the library mem size we compare?


429             (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {

+        uint64_t lib_memsz = lib_php->p_memsz; // check type
+        if (target_vaddr > existing_map->vaddr) {
+            lib_memsz += (target_vaddr - existing_map->vaddr);
+        }
+        lib_memsz = ROUNDUP(lib_memsz, page_size);
+
         if ((existing_map->memsz != page_size) &&
             (existing_map->fd != lib_fd) &&
-            (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {
+            (ROUNDUP(existing_map->memsz, page_size) != lib_memsz)) {


This is kind of similar to what you had, but maybe the target_vaddr varies and becomes offset even more than pagesize at some point?

Curious if that works for clang builds.  In my builds it doesn't change anything, we don't hit target_vaddr > existing_map->vaddr

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3324262154