On Sun, 11 Jan 2026 07:33:12 GMT, Yasumasa Suenaga <[email protected]> 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). > > Yasumasa Suenaga has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Merge remote-tracking branch 'origin/master' into jhsdb-jstack-sighandler > - Fix > - 8374482: SA does not handle signal handler frame in mixed jstack (sorry about delay) Just to discuss an alternative: When LinuxAMD64CFrame.sender() finds nextPC, it could recognise the signal handler trampoline, by looking at the return address nextPC and checking if it points to the bytes of the trampoline: 0x7f5e5e094610 <__restore_rt>: 0x48 0xc7 0xc0 0x0f 0x00 0x00 0x00 0x0f (which look as stable as everything else we are relying on here) Then the new frame is created with boolean isSigTrampoline set as a member in LinuxAMD64CFrame. That avoids needing the symbol lookup to decide if it's a trampoline. Then in LinuxAMD64CFrame: closestSymbolToPC() would return the special string if isSigTrampoline without a lookup. isValidFrame would use the isSigTrampoline member, no new parameter needed. getNextCFA would not need to check if it's a trampoline and pass a value to isValidFrame. sender() would not need the symbol lookup, it has the member boolean. Does that make it simpler overall? It would avoid using the symbol name to know if this is a signal handler trampoline, and having special meaning of "<signal handler called>" in both places. ------------- PR Review: https://git.openjdk.org/jdk/pull/29023#pullrequestreview-3691996749
