On Fri, 9 Jan 2026 20:11:15 GMT, Chris Plummer <[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). > > 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? Yes, this offset is valid since 14 years ago at least. I found the commit which affect to these struct: https://github.com/torvalds/linux/commit/af170c5061dd78512c469e6e2d211980cdb2c193 > 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. There are same problem on aarch64 Linux, and actually I've made a change to fix it: https://github.com/YaSuenag/jdk/commit/b43f4f2172e9213d7e64fa9d9fd08f66eba5d335 However I decided not to include it in this PR because some frames (`VMError::report_and_die` at least) couldn't be unwinded. They seem to use FP as GPR (maybe cause by `-fomit-frame-pointer` when JVM is built). We need to handle DWARF like AMD64 Linux at first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678132974 PR Review Comment: https://git.openjdk.org/jdk/pull/29023#discussion_r2678125742
