Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 21:00:41 GMT, Chris Plummer wrote: >> It looks like the only reason we don't currently see this failure in our CI >> is because the test is being skipped due to >> [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out >> to fix this, but it looks like it is best not to push it until this PR is >> first pushed. > >> It looks like the only reason we don't currently see this failure in our CI >> is because the test is being skipped due to >> [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out >> to fix this, but it looks like it is best not to push it until this PR is >> first pushed. > > Actually I see now it does still pass even when not skipped, but the output > does contain the exception. @plummercj Thanks a lot for your review, but I updated TestJhsdbJstackMixedCore.java to skip on Alpine due to same reason which is reported on [JDK-8376284](https://bugs.openjdk.org/browse/JDK-8376284). I'm happy if you can review again. I fixed merge confliction, but effective change is TestJhsdbJstackMixedCore.java only since your approval. - PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3854313936
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga 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. >> >> >> 0018 0010 001c FDE cie= >> pc=0200..0206 >> DW_CFA_nop >> DW_CFA_nop >> DW_CFA_nop >> >> >> Actually we can see following stacks and exception as following in >> TestJhsdbJstackMixedCore.java: >> >> >> 0x7f14d500204d os::abort(bool, void const*, void const*) [clone .co >> ld] + 0x4 >> 0x7f14d6bd0001 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 >> 0x7f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*, char const*, ...) + 0x88 >> 0x7f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*) + 0x58 >> 0x7f14d68ff1ba JVM_handle_linux_signal + 0x42a >> 0x7f14d7964290 >> 0x7f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash >> 0x7f14be7468ba >> --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 Marked as reviewed by cjplummer (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/29398#pullrequestreview-3741180762
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Thu, 29 Jan 2026 03:43:23 GMT, Chris Plummer wrote: >>> 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. >> >> Yes. >> Remember states should be stacked, but I haven't seen that case. So I >> implemented to save (push) once so far. >> I can fix it, but I want to do it in subsequent PR (for AArch64) because I >> will update register offset handling for generalization. > > Yes, a separate PR would be best. Thinking about this a bit more, it's probably ok to continue to just support a 1 deep stack since that is all we'll likely every see. But if there is ever a second "push", an error should be produced, and if we ever see that error then we can then improve the stack handling. - PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2755673651
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Thu, 29 Jan 2026 00:04:24 GMT, Yasumasa Suenaga wrote: >> 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? > >> 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. > > Yes. > Remember states should be stacked, but I haven't seen that case. So I > implemented to save (push) once so far. > I can fix it, but I want to do it in subsequent PR (for AArch64) because I > will update register offset handling for generalization. Yes, a separate PR would be best. - PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739786274
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Wed, 28 Jan 2026 18:19:44 GMT, Chris Plummer wrote: >> 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. It comes from RBP -8 (return address on stack). Return Address (RA) tends to be CFA - 8 because CFA tends to point RBP, and return address is RBP - 8 in that case. AFAICS return address would be defined in CFI (in CIE at least), thus we can set arbitraly value in initialization. - PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739157882
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Wed, 28 Jan 2026 18:02:19 GMT, Chris Plummer wrote: > 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. Yes. Remember states should be stacked, but I haven't seen that case. So I implemented to save (push) once so far. I can fix it, but I want to do it in subsequent PR (for AArch64) because I will update register offset handling for generalization. - PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2739142879
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga 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. >> >> >> 0018 0010 001c FDE cie= >> pc=0200..0206 >> DW_CFA_nop >> DW_CFA_nop >> DW_CFA_nop >> >> >> Actually we can see following stacks and exception as following in >> TestJhsdbJstackMixedCore.java: >> >> >> 0x7f14d500204d os::abort(bool, void const*, void const*) [clone .co >> ld] + 0x4 >> 0x7f14d6bd0001 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 >> 0x7f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*, char const*, ...) + 0x88 >> 0x7f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*) + 0x58 >> 0x7f14d68ff1ba JVM_handle_linux_signal + 0x42a >> 0x7f14d7964290 >> 0x7f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash >> 0x7f14be7468ba >> --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
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 21:00:41 GMT, Chris Plummer wrote: > Actually I see now it does still pass even when not skipped, but the output > does contain the exception. Yes. New test (TestJhsdbJstackMixedCore.java) introduced in JDK-8374482 highlighted a problem at the function which does not have prologue (in context of calling convention) and its FDE is NOP only. It tends to happen on optimization by compiler. Thus it is different from JDK-8375477. We need to improve DWARF parser and stack unwinder like this PR. - PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3808862526
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 19:21:59 GMT, Chris Plummer wrote: > It looks like the only reason we don't currently see this failure in our CI > is because the test is being skipped due to > [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out > to fix this, but it looks like it is best not to push it until this PR is > first pushed. Actually I see now it does still pass even when not skipped, but the output does contain the exception. - PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3801733809
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga 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. >> >> >> 0018 0010 001c FDE cie= >> pc=0200..0206 >> DW_CFA_nop >> DW_CFA_nop >> DW_CFA_nop >> >> >> Actually we can see following stacks and exception as following in >> TestJhsdbJstackMixedCore.java: >> >> >> 0x7f14d500204d os::abort(bool, void const*, void const*) [clone .co >> ld] + 0x4 >> 0x7f14d6bd0001 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 >> 0x7f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*, char const*, ...) + 0x88 >> 0x7f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig >> ned char*, void const*, void const*) + 0x58 >> 0x7f14d68ff1ba JVM_handle_linux_signal + 0x42a >> 0x7f14d7964290 >> 0x7f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash >> 0x7f14be7468ba >> --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 It looks like the only reason we don't currently see this failure in our CI is because the test is being skipped due to [JDK-8375477](https://bugs.openjdk.org/browse/JDK-8375477). I have a PR out to fix this, but it looks like it is best not to push it until this PR is first pushed. - PR Comment: https://git.openjdk.org/jdk/pull/29398#issuecomment-3801318858
Re: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
> [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. > > > 0018 0010 001c FDE cie= > pc=0200..0206 > DW_CFA_nop > DW_CFA_nop > DW_CFA_nop > > > Actually we can see following stacks and exception as following in > TestJhsdbJstackMixedCore.java: > > > 0x7f14d500204d os::abort(bool, void const*, void const*) [clone .co > ld] + 0x4 > 0x7f14d6bd0001 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 > 0x7f14d6bd07b9 VMError::report_and_die(Thread*, unsigned int, unsig > ned char*, void const*, void const*, char const*, ...) + 0x88 > 0x7f14d6bd0818 VMError::report_and_die(Thread*, unsigned int, unsig > ned char*, void const*, void const*) + 0x58 > 0x7f14d68ff1ba JVM_handle_linux_signal + 0x42a > 0x7f14d7964290 > 0x7f14d780b3a0 Java_jdk_test_lib_apps_LingeredApp_crash > 0x7f14be7468ba > --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.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.j... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring for simplifying - Changes: - all: https://git.openjdk.org/jdk/pull/29398/files - new: https://git.openjdk.org/jdk/pull/29398/files/9a8c7ec8..ecdb4423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29398&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29398&range=00-01 Stats: 90 lines in 1 file changed: 36 ins; 42 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29398.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29398/head:pull/29398 PR: https://git.openjdk.org/jdk/pull/29398
