On Sun, 4 Jan 2026 05:29:58 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames >> only as following: >> >> >> ----------------- 4 ----------------- >> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition >> [0x0000004ae7eff000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14 >> ----------------- 5 ----------------- >> >> >> This is long standing bugs since JDK 9 at least (maybe this includes older >> JDK releases). >> We cannot depend on base pointer to unwind call frames, but SA do that. >> >> This PR use >> [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) >> to find caller frame, then native call frames would be unwinded. >> >> However it has still problems for JIT'ed frames because it does not have a >> hint for unwinder like >> [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). >> But it would affect entire of JIT compilers, so I've limited the change to >> SA. >> >> This change passed serviceability/sa tests on Windows 11. > > Yasumasa Suenaga has updated the pull request incrementally with two > additional commits since the last revision: > > - Fix split pattern for Windows > - Tweak toFrame() src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java line 653: > 651: private native long lookupByName0(String objName, String symName); > 652: private native ClosestSymbol lookupByAddress0(long address); > 653: private native long getFrameBase0(long sp, long pc); I don't see getFrameBase0() being implemented or called. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java line 62: > 60: // However it would not work for dynamic generated code like > CodeBlob because > 61: // HotSpot would not register unwind info like > RtlAddFunctionTable(). > 62: // Thus SA should check whether current PC is in CodeCache at first > when nextPC is null. Suggestion: // The Windows GetStackTrace() Debug API can unwind the frame when given SP, FP, and PC. // However it will not work for dynamic generated code like CodeBlob because // HotSpot will not register unwind info like RtlAddFunctionTable(). // Thus SA should first check whether current PC is in the CodeCache when nextPC is null. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java line 113: > 111: public Frame toFrame() { > 112: // Find top of JavaVFrame relates to this CFrame because FP cannot > be get > 113: // from GetStackTrace DbgHelp API on Windows. Suggestion: // Find the top of JavaVFrame related to this CFrame. The Windows GetStackTrace DbgHelp API // cannot get FP for java frames. src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp line 915: > 913: * Signature: (JJJ)[J > 914: */ > 915: JNIEXPORT jlongArray JNICALL > Java_sun_jvm_hotspot_debugger_windbg_WindbgDebuggerLocal_getSenderRegs0 Some comments would be nice. I think what you are doing is getting the two stack frames starting at the one represented by the incoming registers, and then getting the registers from the 2nd frame. It would be nice to just make this clear in a comment,. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java line 53: > 51: .compile(LINE_MATCHER_STR); > 52: private static final String HEX_STR_PATTERN = "0x([a-fA-F0-9]+)"; > 53: private static final String FIB_SPLIT_PATTERN = "(NoFramePointer!)?" > + NATIVE_FUNCTION_NAME It's unclear to me where NoFramePointer is coming from, and why this works on linux too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677532507 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677524380 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677517894 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677506840 PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2677500840
