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

[Kevin Walls]

On Tue, 3 Feb 2026 10:24:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
>> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
>> 
>> 
>> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007faae4ad9290      <signal handler called>
>> 0x00007faae4cd8e69              ????????
>> 0x00007faaca78ffa1      <nep_invoker_blob>
>> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> It should be:
>> 
>> 
>> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007fb584fd9290      <signal handler called>
>> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
>> 0x00007fb56a78f321      <nep_invoker_blob>
>> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update testcase to skip if kernel debuginfo is not available
>  - Merge branch 'master' into JDK-8376269
>  - Add new function to handle vDSO
>  - Remove unneeded change
>  - Remove 32 bit support
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - 8376269: Mixed jstack cannot find function in vDSO

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 609:

> 607: // Otherwise copy vDSO memory in coredump to temporal memory generated by memfd_create().
> 608: // Returns FD for vDSO (should be closed by caller).
> 609: static int handle_vdso(struct ps_prochandle* ph, char* lib_name, size_t lib_name_len) {

handle_vdso is called with: handle_vdso(ph, lib_name, sizeof(lib_name)):

Was it meant to pass strlen(lib_name)? 
But lib_name here is from the linker info, so that is the short name "linux-vdso.so.1" ?
handle_vdso then mallocs something of the same size, but snprintfs something much longer?   We should just allocate a reasonable sized buffer to create vdso_path, and maybe we don't need the lib_name_len parameter.

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?

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 732:

> 730: 
> 731:       if (lib_name[0] != '\0') { // ignore empty lib names
> 732:          if (strcmp("linux-vdso.so.1", lib_name) == 0 ||

Could we check this lib is at the VDSO address, so we know for sure it's the one and only system vdso?
 link_map_addr + LINK_MAP_ADDR_OFFSET == ps_prochandle->core->vdso_addr
Could do that instead of the name check, or in addition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2763722155
PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2763636696