On Thu, 14 May 2026 01:40:25 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> serviceability/sa/TestJhsdbJstackMixedWithXComp.java failure on CentOS 7 was >> reported. >> >> That error is caused that glibc on CentOS 7 has Personality Routine and LSDA >> (language-specific data area). SA does not support them, and skip them so >> far. Thus DWARF parser could not continue to unwind call stacks. >> >> Personality Routine and LSDA are for exception handling for the language >> which supports exception like C++ (See [LLVM >> document](https://llvm.org/docs/ExceptionHandling.html) for details). They >> are not needed for stack unwinding in debugger like SA, but we need to skip >> DWARF augmentation correctly. >> >> This change has passed serviceability/sa tests on both CentOS 7 and Fedora >> 44. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > Rename to _fde_ptr_encoding I'm seeing failures with TestJhsdbJstackMixedWithXComp and ClhsdbPstack on x64 and aarch64: sun.jvm.hotspot.debugger.DebuggerException: Could not find PC in DWARF at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.DwarfParser.processDwarf0(Native Method) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.DwarfParser.processDwarf(DwarfParser.java:66) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.DwarfCFrame.createDwarfParser(DwarfCFrame.java:57) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.amd64.LinuxAMD64CFrame.sender(LinuxAMD64CFrame.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:195) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) Since this goes to stderr, it was hard to see which thread was the problem, as all of them look like complete stack traces. I modified PStack.java to also print the exception to stdout, and it seems to be a problem with the last thread printed, which is the main launcher thread: ----------------- 1031829 ----------------- 0x00007ff094fe038a __futex_abstimed_wait_common + 0xca 0x00007ff094fe4e34 __pthread_clockjoin_ex + 0x144 0x00007ff095174cd6 CallJavaMainInNewThread + 0xa6 0x00007ff095171dae ContinueInNewThread + 0x6e 0x00007ff095172afc JLI_Launch + 0xb4c 0x000055e53e266ad4 main + 0x134 0x00007ff094f82610 __libc_start_call_main + 0x80 0x00007ff094f826c0 __libc_start_main_alias_2 + 0x80 Note that passing test runs without your changes are showing the same stack. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31085#issuecomment-4447340400
