On Fri, 6 Feb 2026 18:01:17 GMT, Chris Plummer <[email protected]> wrote:
>> We fixed mixed jstack failure when the call stack has frame in vDSO like >> `gettimeofday()` in >> [JDK-8376269](https://bugs.openjdk.org/browse/JDK-8376269). But it has been >> backouted due to build error (see >> [JDK-8377365](https://bugs.openjdk.org/browse/JDK-8377365) for details). >> >> JDK-8376269 uses `memfd_create` to copy vDSO from coredump to temporal >> memory, however it cannot be used on older glibc - some CI works on glibc >> 2.12, it does not have `memfd_create` unfortunately. >> >> Thus this PR proposes to use `tmpfile()` and `fileno()` to copy vDSO, as >> alternatives of `memfd_create()`. It works, and passed all serviceability/sa >> tests on Linux AMD64. >> >> Changes from JDK-8376269 is >> https://github.com/openjdk/jdk/commit/0c315303865efe60de54276bbcf2faf174fd1d9b >> . > > I'm seeing the following failure on linux-x64-debug: > > > Opening core file, please wait... > hsdb> ERROR: address conflict @ 0x7ffe43ff4000 (existing map size = 8192, > size = 3701, flags = 5) > ERROR: can't read shared object's segments > ERROR: failed to read libraries > > > The core file fails to attach as a result of this. @plummercj What is the address 0x7ffe43ff4000? Looks like vDSO... Did you run on same kernel both crasher and clhsdb? I want to know same vDSO is loaded both because the error seems to happen on following code:; if ((existing_map->memsz != page_size) && (existing_map->fd != lib_fd) && (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_memsz, page_size))) { 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); goto err; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/29610#issuecomment-3863385675
