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

Yasumasa Suenaga ysuenaga at openjdk.org
Thu Oct 9 23:34:20 UTC 2025 

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 * java.lang.invoke.LambdaForm$MH+0x000000000c050800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x00007f8f4b33fe48 * jdk.internal.foreign.abi.DowncallStub+0x000000000c048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c04e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x00007f8f4b33fd00 * java.lang.invoke.LambdaForm$MH+0x000000000c04c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x00007f8f4b33fd00 * Test.run() bci:21 line:28 (Interpreted frame)
0x00007f8f4b33e098 <StubRoutines (continuation stubs)>
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b340206 <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe48 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b3386fd <StubRoutines (initial stubs)>
0x00007f8f62bc0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f8f62bc11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f8f62bc17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f8f62d83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f8f62c02806 JavaThread::thread_main_inner() + 0x256
0x00007f8f63865b57 Thread::call_run() + 0xb7
0x00007f8f632fc588 thread_native_entry(Thread*) + 0x128
0x00007f8f6464ff54 start_thread + 0x2e4


According to stack layout described in continuationFreezeThaw.cpp and stub implementation in `StubGenerator::generate_cont_thaw()` in stubGenerator_x86_64.cpp, we cannot calculate caller SP from `CodeBlob` for continuation stub. We need to restore SP from `_cont_entry` in `JavaThread`.

After this fix, we can see following stacks:


----------------- 39371 -----------------
"ForkJoinPool-1-worker-1" #27 daemon prio=5 tid=0x00007fe83036f230 nid=39371 runnable [0x00007fe815e06000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007fe839b17462      __syscall_cancel_arch + 0x32
0x00007fe839b0b75c      __internal_syscall_cancel + 0x5c
0x00007fe839b67c37      __GI___nanosleep + 0x17
0x00007fe839b7a14e      __sleep + 0x3e
0x00007fe81f3a859e      <nep_invoker_blob>
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x0000000041047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x0000000041051400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x00007fe81f33fe48      * jdk.internal.foreign.abi.DowncallStub+0x0000000041048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x000000004104e800.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.invoke.LambdaForm$MH+0x000000004104d800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x00007fe81f33fd00      * Test.run() bci:21 line:28 (Interpreted frame)
0x00007fe81f33e098      <StubRoutines (continuation stubs)>
0x00007fe81f33fd00      * jdk.internal.vm.Continuation.run() bci:122 line:248 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.VirtualThread$$Lambda+0x0000000041029b58.run() bci:4 (Interpreted frame)
0x00007fe81f340206      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:4 line:1753 (Interpreted frame)
0x00007fe81f33fe9a      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:1 line:1745 (Interpreted frame)
0x00007fe81f33fe9a      * java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() bci:51 line:1662 (Interpreted frame)
0x00007fe81f33fe48      * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Interpreted frame)
0x00007fe81f3386fd      <StubRoutines (initial stubs)>
0x00007fe837fc0a7e      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007fe837fc11b3      JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007fe837fc17bb      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007fe838183a90      thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007fe838002806      JavaThread::thread_main_inner() + 0x256
0x00007fe838c65b57      Thread::call_run() + 0xb7
0x00007fe8386fc588      thread_native_entry(Thread*) + 0x128
0x00007fe839b0ef54      start_thread + 0x2e4


I saw this issue on Linux AMD64. I'm not sure but it might happen on another platforms.

I haven't yet created a complete reproducer, but Test.java on JBS can be reproduced with high probability.

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

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

Changes: https://git.openjdk.org/jdk/pull/27728/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369505
  Stats: 93 lines in 6 files changed: 91 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728

PR: https://git.openjdk.org/jdk/pull/27728

More information about the serviceability-dev mailing list