On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer <[email protected]> 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(... > > I applied the changes to AARCH64Frame.java and they seem to fix the issue > with the exception. I'm seeing two different stack traces (see below), and > neither is identical to your fixed stack trace. I don't see `<StubRoutines > (continuation stubs)>`. Instead I see a frame for > `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see > `<StubRoutines (initial stubs)>` or any of the frames that come after it. > Maybe these are just expected platform differences. > > "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 > runnable [0x0000000172761000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, > long, int) @bci=10 (Interpreted frame) > - > java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, > long, int, java.lang.Object) @bci=21 (Interpreted frame) > - > jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, > java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) > - > java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, > java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, > int) @bci=44 (Interpreted frame) > - > java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, > int, java.lang.Object) @bci=18 (Interpreted frame) > - Test.run() @bci=21, line=28 (Interpreted frame) > - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, > boolean, boolean) @bci=0 (Compiled frame) > - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) > - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted > frame) > - java.lang.VirtualThread$$Lambda+0x000003fe01027670.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.F... @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least). Thanks @pchilano for explaining the problem, I understood it relates to unmount, it is triggered by `System.out.println` and we can replace it to `Thread.yield`. I can convert Test.java to JTREG test of course, However I'm not sure how we can reproduce this issue 100%. I guess the problem is very similar with race-condition - dependent on timing. Do you have any idea to happen the problem exactly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392807014
