On Tue, 30 Sep 2025 10:19:46 GMT, Kevin Walls <[email protected]> wrote:
>> 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?
>
>> Do we understand why this offset is happening?
>
> It looks like the binary is just built differently, clang or the linker or
> some combination arranges things differently to what we have seen from gcc.
>
> Maybe it's enough to say there doesn't have to be a 1:1 mapping from program
> headers to segments in the process.
> We can have a core file segment that contains more than one program header
> from the library (that 0x19000 size segment at the libjimage base address).
>
>
> So, new question:
>
> we must have been through this loop already, in the libjimage example with
> the first LOAD PH of size 0x000000000000841c at the library base address.
>
> Did that pass the same test?
> No it can't, the mapping is 0x19000 and size 0x841c does not round up to that.
> I think we must ignore the first LOAD PH from the clang build as we check:
>
> 408 } else if (lib_php->p_flags != existing_map->flags) {
>
> ..and the first LOAD PH from
> https://bugs.openjdk.org/secure/attachment/116209/3libjimage_all.txt
> ..is a Read only, not execute.
>
> This should be OK in this case:
>
> https://bugs.openjdk.org/secure/attachment/116199/3core_all.txt
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000141000 0x00007fa9ff0e4000 0x0000000000000000
> 0x0000000000019000 0x0000000000019000 R E 0x1000
>
>
> Filesize and memsiz both 0x019000 must mean the core contains everything, we
> don't need either of these from the library.
> But there is no harm in continuing past the problematic check and populating
> existing_map from the library.
Ok. That's mostly making sense to me. I'm still a bit fuzzy on it, but that's
ok. Has testing been done to make sure this doesn't break anything with gcc?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2395729935
