RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang [v7]
Chris Plummer
cjplummer at openjdk.org
Mon Sep 29 20:52:37 UTC 2025
On Mon, 29 Sep 2025 10:50:36 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 one additional commit since the last revision:
>
> cc
src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 428:
> 426: lib_memsz += target_vaddr - existing_map->vaddr;
> 427: }
> 428:
I think this change looks good, but just want to make sure I'm understanding it properly. Kevin commented the following:
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
So the problem here is that we were expecting 0x00007fa9ff0e4000 but got 0x7fa9ff0e4440. Basically target_vaddr is at an unexpected offset from existing_map->vaddr. The fix is to ad this offset to lib_memsz so the error is no longer triggered. Do we understand why this offset is happening?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2389240885
More information about the serviceability-dev
mailing list