RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]

[Chris Plummer]

On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline.
>> However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only.
>> 
>> 
>> 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206
>>   DW_CFA_nop
>>   DW_CFA_nop
>>   DW_CFA_nop
>> 
>> 
>> Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java:
>> 
>> 
>> 0x00007f14d500204d      os::abort(bool, void const*, void const*) [clone .co
>> ld] + 0x4
>> 0x00007f14d6bd0001      VMError::report_and_die(int, char const*, char const
>> *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c
>> onst*, int, unsigned long) + 0x6f1
>> 0x00007f14d6bd07b9      VMError::report_and_die(Thread*, unsigned int, unsig
>> ned char*, void const*, void const*, char const*, ...) + 0x88
>> 0x00007f14d6bd0818      VMError::report_and_die(Thread*, unsigned int, unsig
>> ned char*, void const*, void const*) + 0x58
>> 0x00007f14d68ff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007f14d7964290      <signal handler called>
>> 0x00007f14d780b3a0      Java_jdk_test_lib_apps_LingeredApp_crash
>> 0x00007f14be7468ba
>> ----------System.err:(20/1429)----------
>> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun....
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring for simplifying

src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 105:

> 103:   _return_address_reg = RA;
> 104:   _cfa_offset = 0;
> 105:   _ra_cfa_offset = 8;

Can you explain where this offset of 8 is coming from. I see it used in a few places.

src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp line 122:

> 120:   int rem_cfa_offset = 0;
> 121:   int rem_ra_cfa_offset = 8;
> 122:   int rem_bp_cfa_offset = INT_MAX;

Although not introduced by this PR, I noticed the "remember state" code while reading through our existing sources and also reading up on the .eh_frame format. Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep. Is this something that should be eventually fixed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2737921950
PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2737858165