RFR: 8374469: Mixed jstack does not work on Windows [v2]

[Yasumasa Suenaga]

On Thu, 15 Jan 2026 01:29:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> On my Windows 11 25H2, mixed jstack works correctly like following:
>> 
>>   <snip>
>> 
>> 0x00007ff8105c10c4      NoFramePointer!fib + 0x28
>> 0x00007ff8105c10c4      NoFramePointer!fib + 0x28
>> 0x00007ff8105c101d      NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0x1d
>> 0x000001c5903afbf8      * LingeredAppWithNativeMethod.callJNI(java.lang.Object, int) bci:0 (Interpreted frame)
>>                         * LingeredAppWithNativeMethod.callNative() bci:47 line:54 (Interpreted frame)
>>                         * LingeredAppWithNativeMethod.callback(long) bci:8 line:63 (Interpreted frame)
>> 
>>   <snip>
>> 
>> 
>> Do you mean multiple jstacks are shown in .jtr file with message such as "DEBUG: Iteration: 1 - Test didn't trigger interesting condition." ? If yes, I think it is expected.
>> 
>> TestJhsdbJstackMixed.java seems to check at `isFibAndAlignedAddress` whether instruction address (PC) is aligned or not. I saw the condition is met in early on Linux x64, but it seems to take some calls on Windows x64. I'm not sure why we need to check this (I checked [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091) which introduced it, but I haven't yet understood the reason).
>
> "NoFramePointerJNIFib" #28 prio=5 tid=0x0000023fa4432290 nid=20612 runnable [0x000000d0370fe000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007ffbe5fd10a8	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xa8
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10db	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xdb
> 0x00007ffbe5fd10d0	NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI + 0xd0
> 0x00007ffbe5fd10db	NoFramePointe...

I don't know why these call stacks were produced... It's strange.
I tested this PR with cl.exe 19.50.35721 by VS 2026 18.1.1, I didn't see such call stacks.

`callJNI()` makes recursive call, but it should include Java upcall (you can see it as LingeredAppWithNativeMethod.callback()`)

Top of call stacks is `callJNI()`, thus I believe it has valid RSP/RBP/RIP (passed by `WindbgCDebugger::topFrameForThread`). `callJNI` is JNI function in NoFramePointer.dll generated by cl.exe (in usual (I believe) on OpenJDK build environment), thus I think `GetStackTrace` API works.
Each `NoFramePointer!Java_LingeredAppWithNativeMethod_callJNI` has instruction address, it means they were unwinded by the API, thus I think we need to investigate assembly code in NoFramePointer.dll to know what happens...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29019#discussion_r2692734686