On Thu, 12 Nov 2026 03:01:07 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> DebuggerException occurs in [`new >> AARCH64DwarfParser(libptr)`](https://github.com/jyukutyo/jdk/blob/0af9bbc05f5909de16053a3ee65e0b0ba829d2bf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/DwarfCFrame.java#L59) >> in DwarfCFrame. The DebuggerException occurs before calling >> `DwarfParser#processDwarf()`. So the fallback to `.debug_frame` doesn't >> occur in this case. > >> DebuggerException occurs in [`new >> AARCH64DwarfParser(libptr)`](https://github.com/jyukutyo/jdk/blob/0af9bbc05f5909de16053a3ee65e0b0ba829d2bf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/DwarfCFrame.java#L59) >> in DwarfCFrame. The DebuggerException occurs before calling >> `DwarfParser#processDwarf()`. So the fallback to `.debug_frame` doesn't >> occur in this case. > > I think root cause is that SA does not try `.debug_frame` in executable when > `DwarfParser` (C++ class) is created. I could reproduce the problem on AMD64 > Linux. We can fix it with your change + following patch. We can expect > `createDwarfParser()` would not throw `DebuggerException`, and we can see all > of call stacks from `wait_for_release()` rather than show its frame only > because `.debug_frame` has FDE for it. > > I recommend you to check it on Alpine Linux because its binary (e.g. musl C) > does not have enough `.eh_frame` and DWARF what SA should refer is in > `.debug_frame` in debuginfo. > > > diff --git a/make/test/JtregNativeHotspot.gmk > b/make/test/JtregNativeHotspot.gmk > index d44cad10b1f..c84955bb36e 100644 > --- a/make/test/JtregNativeHotspot.gmk > +++ b/make/test/JtregNativeHotspot.gmk > @@ -75,12 +75,12 @@ ifeq ($(call isTargetOs, linux), true) > HOTSPOT_JTREG_LIBRARIES_LIBS_libSuspendInCritical += -latomic > endif > else > - HOTSPOT_JTREG_EXCLUDE += libtest-rw.c libtest-rwx.c \ > + HOTSPOT_JTREG_EXCLUDE += libtest-rw.c libtest-rwx.c libNoEhFrame.c \ > exeinvoke.c exestack-gap.c exestack-tls.c libAsyncGetCallTraceTest.cpp > endif > > ifneq ($(call isTargetOs, linux)+$(call isTargetCpu, aarch64), true+true) > - HOTSPOT_JTREG_EXCLUDE += libTestSVEWithJNI.c libNoEhFrame.c > + HOTSPOT_JTREG_EXCLUDE += libTestSVEWithJNI.c > endif > > ifeq ($(call isTargetOs, windows), true) > diff --git a/src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp > b/src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp > index 83df07d7ab2..50cfe5bf859 100644 > --- a/src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp > +++ b/src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp > @@ -431,15 +431,12 @@ bool DwarfParser::process_dwarf(const uintptr_t pc) { > bool result = false; > // try again with .debug_frame section if it hasn't been tried yet. > if (!_lib->frame.tried_debug_frame && _lib->fd != -1) { > - // attempts to load .debug_frame from executables. > frame_info frame = {}; > - if (!read_frame(".debug_frame", _lib->fd, &frame)) { > - // attempts again to load .debug_frame from debuginfo if it could... @YaSuenag Thank you for the suggestion. I've run some cases after applying your patch. 1. no `.eh_frame` 2. has `.eh_frame` but it doesn't cover the target function and `.debug_frame` in the library has the FDE of the function 3. 2 + revert the fix for `process_dwarf()` I think `process_dwarf()` in dwarf.cpp should be unchanged. In the 2nd case, the caller information wasn't shown when `.eh_frame` existed but didn't cover the function. The 3rd case showed the information although the 2nd case didn't. The 1st case showed the caller information. I've run the 3rd case on Alpine Linux and SA read `.debug_frame` in debuginfo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33839#issuecomment-6820601635
