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

[Kevin Walls]

On Fri, 23 Jan 2026 02:09:30 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).
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring

Thanks for your efforts on this.

Yes, the bytes were Linux x64 specific.  I was thinking that the check would be in a file that is platform/arch specific, and would check for the specific signal return method for that architecture.

If we do this with symbol names, or by looking at the bytes, it looks odd to have a generic method in the symtab file or LinuxCDebugger/LinuxDebuggerLocal that recognises a signal return method from any platform.

If it's simpler to use symbol names that's fine, but I'm saying if we implement the recognition in LinuxADM64CFrame, then it knows what platform/arch this is, and can check for the specific symbol or bytes.

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

PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789252429