RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]

[Yasumasa Suenaga]

On Thu, 5 Feb 2026 10:29:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> Was it meant to pass strlen(lib_name)?
>> 
>> `lib_name` is allocated with `char[BUF_SIZE]`, and is used in subsequent code in `read_shared_lib_info()`, thus I want to overwrite it to real path of vDSO binary at `handle_vdso()`. Hence I passed buffer size, not length of string.
>> 
>>> Then handle_vdso checks /lib/modules... exists, and then opens it with pathmap_open? So it has to exist without pathmap, but may also be in the SA_ALTROOT directory.
>> Should handle_vdso also try pathmap_open() first?
>> 
>> Good catch! Fixed in new commit.
>
> Ak ok yes thanks, lib_name is a local char[] (it's defined a long way back in the method!). 
> Comment which might be clearer:
> 
> // Check for vDSO binary in kernel directory (/lib/modules/<version>/vdso), rewrite the
> // given lib_name string if found.
> // Otherwise copy vDSO memory in coredump to temporal memory generated by memfd_create().
> // Returns FD for vDSO (should be closed by caller), or -1 on error.

Thanks! updated.

>> I think it is better to compare with `lib_base` like this:
>> 
>>          if (lib_base == ph->core->vdso_addr) {
>>            lib_fd = handle_vdso(ph, lib_name, sizeof(lib_name));
>>          } else {
>> 
>> However it is difficult because `lib_base` is calculated in subsequent code with program header in ELF (in `find_base_address`).
>> 
>> Maybe we can use `lib_base_diff` at here because debug log says virtual address for vDSO is same with vaddr in `l_addr` in `struct link_map` as following, but I'm not sure.
>> 
>> libsaproc DEBUG: first link map is at 0x7fa08970d2f0
>> libsaproc DEBUG: replace vDSO: linux-vdso.so.1 -> /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so
>> libsaproc DEBUG: reading library /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so @ 0x7fa0896d2000 [ 0x7fa0896d2000 ]
>> libsaproc DEBUG: overwrote with new address mapping (memsz 8192 -> 8192)
>> libsaproc DEBUG: /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so [0] 0x7fa0896d2000-0x7fa0896d4000: base = 0x7fa0896d2000, vaddr = 0x0, memsz = 0x1883, filesz = 0x1883
>
> Yes I think we should compare (lib_base_diff == ph->core->vdso_addr),
> I'm seeing the VDSO in /lib/modules with a load address of zero, so lib_base_diff read from linkmap must be the real virtual address of the vdso.

I updated condition in new commit.

I also confirmed virtual address of first load segment of ELF program header in vDSO is zero as following.
I'm not sure it happens on all of Linux (AMD64) TBH, but vDSO is special, so I guess it works.


Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001883 0x0000000000001883  R E    0x1000
  DYNAMIC        0x0000000000000438 0x0000000000000438 0x0000000000000438
                 0x0000000000000120 0x0000000000000120  R      0x8
  NOTE           0x0000000000000570 0x0000000000000570 0x0000000000000570
                 0x0000000000000068 0x0000000000000068  R      0x4
  GNU_EH_FRAME   0x00000000000005d8 0x00000000000005d8 0x00000000000005d8
                 0x0000000000000064 0x0000000000000064  R      0x4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2768612793
PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2768611662