On Fri, 23 Oct 2026 04:25:31 GMT, Long Yang <[email protected]> wrote:
>> Thanks, I agree that <= is correct, and the current SA tests do pass. >> However, on x86_64 and AArch64, a raw return PC may successfully resolve to >> the next CFI row, so the exception-based PC−1 fallback would not catch this >> case. I overlooked this interaction during my earlier review; sorry about >> that. > >> Small question: What is this change for? I didn't see any discussion or >> explanatory comment about this. I wonder how this may affect other CPU >> platforms, like x86/aarch64. > > Thanks for the review. > > Without the change, the > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java test fails. > > ... > 0x0000003f80dce2c8 JVM_handle_linux_signal + 0x295 > 0x0000003f81d3d620 __vdso_rt_sigreturn <signal trampoline> > 0x0000003f7c2b7560 Java_jdk_test_lib_apps_LingeredApp_crash + 0x18 > 0x0000003f67741a7a * > jdk.test.lib.apps.LingeredApp.mainLoop(java.lang.String[]) bci:139 line:663 > (Interpreted frame) > * > jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) bci:48 line:626 > (Interpreted frame) > 0x0000003f67736afa <StubRoutines (initial stubs)> > ... > > TEST RESULT: Failed. Execution failed: `main' threw exception: > java.lang.RuntimeException: 'jdk.test.lib.apps.LingeredApp.crash()' missing > from stdout/stderr > > The correct result is > > 0x0000003fa7fce2c8 JVM_handle_linux_signal + 0x295 > 0x0000003fa8e2f620 __vdso_rt_sigreturn <signal trampoline> > 0x0000003fa8c2e560 Java_jdk_test_lib_apps_LingeredApp_crash + 0x18 > 0x0000003f8f741a7a * jdk.test.lib.apps.LingeredApp.crash() bci:0 > (Interpreted frame) > * > jdk.test.lib.apps.LingeredApp.mainLoop(java.lang.String[]) bci:139 line:663 > (Interpreted frame) > * jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) > bci:48 line:626 (Interpreted frame) > 0x0000003f8f736afa <StubRoutines (initial stubs)> > > > The reason is: > Segment fault is triggered at `0x0000003fa8c2e560 > Java_jdk_test_lib_apps_LingeredApp_crash `, > the exact PC 0x0000003fa8c2e560 is passed to dwarf.cpp. With the original > condition, dwarf.cpp selects the CFA rule at address 000000000000055e, this > is not correct for exact PC, the rule at 0000000000000560 is expected. The > rules to unwind CFA and s0 are different. > > 0000003c 0000000000000024 00000040 FDE cie=00000000 > pc=0000000000000548..0000000000000566 > LOC CFA ra s0 > ... > 000000000000055e s0+0 u c-16 > 0000000000000560 sp+16 u u > 0000000000000564 sp+0 u u > > > My change is to make dwarf.cpp work correctly for exact PCs from signal > trampoline. Thanks for considering my question. I see https://bugs.openjdk.org/browse/JDK-8395826 has been resolved. Is this fix ready to go? The same issue still triggers irregularly on my linux-riscv64 platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33374#discussion_r4420769083
