On Fri, 23 Oct 2026 03:14:50 GMT, Dingli Zhang <[email protected]> wrote:
>> I will approve this change when the confliction is resolved.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33374#discussion_r4356076430
