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... What's the easiest way to determine this? > 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 you are asking if the core file was generated on the same machine as SA is run on, yes. I'm just running the jtreg core file tests. All the core file tests fail in this way. This is with our mach5 system. I'll try on my local machine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29610#issuecomment-3863419689
