On Thu, 14 May 2026 03:54:08 GMT, Chris Plummer <[email protected]> wrote:
>> 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.
Thanks @plummercj for the report!
I reverted changes in LinuxAMD64CFrame and LinuxAARCH64CFrame to stop unwinder
if SA cannot find PC in DWARF rather than throwing exception.
I tested on following environments, and I couldn't see that call stacks:
* x64
* Fedora 44
* Rocky Linux 9.5
* Ubuntu 26.04
* CentOS 7
* aarch64
* Rocky Linux 9.5
According to your repot, SA does not seem to be able to reach `_start()`. In
Fedora 44, it was shown as caller of `__libc_start_main_alias_2()`.
In CentOS 7, I saw strange function info in `java`.
In `readelf --debug-dump=frames`, there are the FDE which contains PC what SA
attempts to find. It matches PC range in `_start()`. However size of `_start()`
is zero as following in `readelf -sW`. It is same with C runtime object
(crt1.o).
Num: Value Size Type Bind Vis Ndx Name
36: 00000000000012ae 0 FUNC GLOBAL DEFAULT 13 _start
I'm not sure (and I couldn't find related known issue(s)), but I guess it is
not a bug on SA.
> Note that passing test runs without your changes are showing the same stack.
Do you mean mixed call stack? or call stacks in the exception?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31085#issuecomment-4448525165
