RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64

[Chris Plummer]

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         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.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

I'm seeing a similar exception on macosx-aarch64 with your test, however, I don't see all the frames that you are seeing. The stack dump stops at `Test.run()`.

Also, on threads that are fully dumped, the output is different than you working dump above. I'm not sure if this is expected:


"ForkJoinPool-1-worker-6" #33 daemon prio=5 tid=0x0000000147856810 nid=41731 runnable [0x0000000172df5000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
 - java.lang.invoke.LambdaForm$MH+0x0000000801047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x0000000801054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
 - jdk.internal.foreign.abi.DowncallStub+0x0000000801048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000080104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000080104e000.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
 - Test.run() @bci=21, line=28 (Interpreted frame)
 - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1487 (Interpreted frame)
 - java.lang.VirtualThread.run(java.lang.Runnable) @bci=62, line=456 (Interpreted frame)
 - java.lang.VirtualThread$VThreadContinuation$1.run() @bci=15, line=248 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter0() @bci=4, line=322 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter(jdk.internal.vm.Continuation, boolean) @bci=1, line=313 (Interpreted frame)
 - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
 - jdk.internal.vm.Continuation.run() @bci=122, line=248 (Interpreted frame)
 - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
 - java.lang.VirtualThread$$Lambda+0x0000000801027670.run() @bci=4 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame)
 - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame)

I can see if your changes are applicable to aarch64. If they work, then great, if not, I'll probably need some help getting it right.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391989222
PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391996631