On Tue, 3 Feb 2026 10:24:43 GMT, Yasumasa Suenaga <[email protected]> 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 <[email protected]> > - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > > Co-authored-by: Chris Plummer <[email protected]> > - 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
