RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack with -Xcomp [v2]

Fei Yang fyang at openjdk.org
Fri Oct 24 01:28:05 UTC 2025


On Thu, 23 Oct 2025 07:22:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Sure. This is what I got on my amd64 machine:
>> 
>> ```$ make test TEST="serviceability/sa/TestJhsdbJstackMixedWithXComp.java"```
>> 
>> [TestJhsdbJstackMixedWithXComp.jtr.txt](https://github.com/user-attachments/files/23091141/TestJhsdbJstackMixedWithXComp.jtr.txt)
>
> @RealFYang Thank you for sharing it!
> 
> I think it might be caused by binary difference, it is not caused by this PR at least. So I think we can go forward this PR, make sence?
> 
> Your .jtr file implies stack unwinding was failed from the function by libc in following:
> 
> ----------------- 2310034 -----------------
> "SteadyStateThread" #39 prio=5 tid=0x00007fd2600358a0 nid=2310034 waiting for monitor entry [0x00007fd2351f4000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>    JavaThread state: _thread_blocked
> 0x00007fd267930f16      __futex_abstimed_wait_common + 0xc6
> ----------------- 2310033 -----------------
> "ForkJoinPool-1-worker-2" #38 daemon prio=5 tid=0x00007fd1ec006600 nid=2310033 runnable [0x00007fd2352f5000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007fd26797a545      __clock_nanosleep + 0x65
> 0x00007fd26797ee53      __GI___nanosleep + 0x13
> 
> 
> Native stack unwinding on Linux AMD64 depends on DWARF (in AArch64, it depends on FP (x29) yet).
> I downloaded and checked libc.so.6 in libc6-udeb_2.41-12_amd64.udeb, it has `.eh_frame` section which would be used by `DwarfParser`, but it does not have any symbols, and not have `.gnu_debuglink` ELF section. OTOH Fedora 43 which I confirmed to work has both symbols and `.gnu_debuglink`.
> 
> They are used for symbol resolution, not stack unwinding. However other difference(s) in binary might affect statck unwinding. Thus I think it is not a problem caused by this PR.

Hi, I am just wondering if there is a workaround for these platforms. Or can we simply skip this when testing on them? Say, if this depends on the availability of pstack, maybe we can add check for that then. Otherwise, we may introduce test noise for people who use them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2458277165


More information about the serviceability-dev mailing list