RFR: 8374482: SA does not handle signal handler frame in mixed jstack

[Chris Plummer]

On Sat, 3 Jan 2026 10:22:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> SA does not handle signal handler frame in mixed jstack as following:
> 
> 
> ----------------- 1789 -----------------
> "main" #1 prio=5 tid=0x00007f654c010000 nid=0x6fd runnable [0x00007f6551c0b000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f6551c0e735 __GI_abort + 0x8b
> 0x00007f65511feb39 _ZN2os5abortEbPvPKv + 0x19
> 0x00007f6551427569 _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x579
> 0x00007f6551427deb _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b
> 0x00007f6551427e1e _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e
> 0x00007f6551209950 JVM_handle_linux_signal + 0x1c0
> 0x00007f65511fd538 _ZL13signalHandleriP7siginfoPv + 0x38
> 0x00007f6551c27290 ????????
> 0x00007f653400f890 * NativeSEGV.doSEGV() bci:0 (Interpreted frame)
> 0x00007f6534009c43 * NativeSEGV.main(java.lang.String[]) bci:76 line:37 (Interpreted frame)
> 0x00007f6534000849 <StubRoutines>
> 0x00007f6550e847e9 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x3b9
> 0x00007f6550eff1ba _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.65.constprop.193 + 0x1ba
> 0x00007f6550f01824 jni_CallStaticVoidMethod + 0x164
> 0x00007f6551e0582d JavaMain + 0xe4d
> 0x00007f6551c7f464 start_thread + 0x2e4
> 
> 0x7f6551c27290 is a signal handler frame, and its caller is native frame. However jstack reports the caller is Java frame (`NativeSEGV.doSEGV()`).
> 
> It should be like following:
> 
> 
> 0x00007fdbd170321a JVM_handle_linux_signal + 0x42a
> 0x00007fdbd267b290 <signal handler called>
> 0x00007fdbc7ecb3b1 Java_NativeSEGV_doSEGV + 0x18
> 0x00007fdbb67468ba * NativeSEGV.doSEGV() bci:0 (Interpreted frame)
> 
> 
> This is long standing bug (since JDK 9 at least).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java line 217:

> 215: 
> 216:      var sym = closestSymbolToPC();
> 217:      if (sym != null && sym.getName().equals("<signal handler called>")) {

You are using "<signal handler called>" in both C and java code. I think this should at least be called out in comments at each location so the readers knows they have to be kept in sync.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 49:

> 47: 
> 48:   public static Address getRegFromSignalTrampoline(Address sp, int index) {
> 49:     // ucontext_t locates at top of stack.

Did you mean "is located"?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java line 52:

> 50:     // See definition of rt_sigframe in arch/x86/include/asm/sigframe.h
> 51:     // in Linux Kernel.
> 52:     Address addrUCMContext = sp.addOffsetTo(40); // offsetof(ucontext_t, uc_mcontext) = 40

Can we count on 40 always working across all kernels?

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 37:

> 35:  * @bug 8374482
> 36:  * @requires (os.family == "linux") & (vm.hasSA)
> 37:  * @requires os.arch == "amd64"

Do you think your fixes could also be applied to aarch64? I assume the same problem exists there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677486035
PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677491443
PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677493822
PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2677471639