JDK-8306679 : com/sun/jdi/InterruptHangTest.java asserts with -Xcomp -Dmain.wrapper=Virtual options
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-04-21
  • Updated: 2024-09-23
  • Resolved: 2024-09-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b16Fixed
Related Reports
Relates :  
JDK-8324868 - debug agent does not properly handle interrupts of a virtual thread
Relates :  
JDK-8043571 - [REDO] JDK-8041934 com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
Description
If you run com/sun/jdi/InterruptHangTest.java with "-Xcomp -Dmain.wrapper=Virtual", you will get the following on about 2/3rds of the runs on all platforms except windows:

#  Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S63265/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c5ec6d5f-d8aa-4e2f-8c1f-01846ed52adf/runs/37522b1b-b6e4-424b-b868-52f1f824e36d/workspace/open/src/hotspot/share/prims/jvmtiThreadState.cpp:795), pid=3340324, tid=3340459
#  assert(_cur_stack_depth == num_frames) failed: cur_stack_depth out of sync _cur_stack_depth: 13 num_frames: 12

The test actually fails with:

java.lang.RuntimeException: Non-zero debuggee exitValue: 134
	at TestScaffold.waitForVMDisconnect(TestScaffold.java:744)
	at TestScaffold.resumeToVMDisconnect(TestScaffold.java:972)
	at TestScaffold.listenUntilVMDisconnect(TestScaffold.java:705)
	at InterruptHangTest.runTests(InterruptHangTest.java:181)
	at TestScaffold.startTests(TestScaffold.java:434)
	at InterruptHangTest.main(InterruptHangTest.java:118)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1592)

Here's the full stack trace at the time of the assert:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x106868c]  JvmtiThreadState::cur_stack_depth()+0x13c  (jvmtiThreadState.cpp:795)
V  [libjvm.so+0x1027e84]  JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0xa4  (jvmtiExport.cpp:1921)
V  [libjvm.so+0x102d638]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x238  (javaThread.hpp:650)
V  [libjvm.so+0xd27a88]  InterpreterRuntime::post_method_exit(JavaThread*)+0xc8  (interpreterRuntime.cpp:1241)
j  java.lang.invoke.LambdaForm$MH+0x0000000801008800.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+37 java.base@21-ea
J 4211  jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base@21-ea (0 bytes) @ 0x0000fffba8ca94f4 [0x0000fffba8ca93c0+0x0000000000000134]
J 4215 c2 jdk.internal.vm.Continuation.run()V java.base@21-ea (586 bytes) @ 0x0000fffba8cab82c [0x0000fffba8cab380+0x00000000000004ac]
J 4209 c2 java.lang.VirtualThread.runContinuation()V java.base@21-ea (128 bytes) @ 0x0000fffba8ca9a18 [0x0000fffba8ca98c0+0x0000000000000158]
J 4207 c2 java.lang.VirtualThread$$Lambda+0x000000080104ba80.run()V java.base@21-ea (8 bytes) @ 0x0000fffba8ca9034 [0x0000fffba8ca8fc0+0x0000000000000074]
J 5222 c2 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec()Z java.base@21-ea (11 bytes) @ 0x0000fffba8d88d3c [0x0000fffba8d88cc0+0x000000000000007c]
J 5198 c2 java.util.concurrent.ForkJoinTask.doExec()I java.base@21-ea (37 bytes) @ 0x0000fffba8d83a04 [0x0000fffba8d83980+0x0000000000000084]
J 5220 c2 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V java.base@21-ea (83 bytes) @ 0x0000fffba8d8825c [0x0000fffba8d881c0+0x000000000000009c]
J 5212 c2 java.util.concurrent.ForkJoinPool.scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;II)I java.base@21-ea (263 bytes) @ 0x0000fffba8d876a8 [0x0000fffba8d87480+0x0000000000000228]
J 4188 c2 java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V java.base@21-ea (60 bytes) @ 0x0000fffba8ca532c [0x0000fffba8ca5280+0x00000000000000ac]
J 4180 c2 java.util.concurrent.ForkJoinWorkerThread.run()V java.base@21-ea (180 bytes) @ 0x0000fffba8ca06a4 [0x0000fffba8ca0600+0x00000000000000a4]
v  ~StubRoutines::call_stub 0x0000fffba819017c
V  [libjvm.so+0xd44174]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x434  (javaCalls.cpp:415)
V  [libjvm.so+0xd44688]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x248  (javaCalls.cpp:329)
V  [libjvm.so+0xd44874]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x64  (javaCalls.cpp:191)
V  [libjvm.so+0xe8f1d4]  thread_entry(JavaThread*, JavaThread*)+0xa0  (jvm.cpp:2918)
V  [libjvm.so+0xd779a8]  JavaThread::thread_main_inner()+0x184  (javaThread.cpp:717)
V  [libjvm.so+0x15b2be0]  Thread::call_run()+0xac  (thread.cpp:224)
V  [libjvm.so+0x13118c8]  thread_native_entry(Thread*)+0x134  (os_linux.cpp:740)
C  [libpthread.so.0+0x7908]  start_thread+0x188
Comments
Changeset: a8f143c6 Branch: master Author: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2024-09-14 22:50:50 +0000 URL: https://git.openjdk.org/jdk/commit/a8f143c6abe7669c232cabda3a4e8df726de036e
14-09-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20943 Date: 2024-09-11 02:57:33 +0000
11-09-2024
This issue is related to virtual threads implementation, is not a dup of JDK-8043571.
04-09-2024
The suggested fix is: git diff src/hotspot/share/runtime/continuationFreezeThaw.cpp diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 0a763d76bad..b6ae04113f2 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -2043,7 +2043,7 @@ NOINLINE intptr_t* ThawBase::thaw_slow(stackChunkOop chunk, bool return_barrier) assert(_cont.chunk_invariant(), ""); - JVMTI_ONLY(if (!return_barrier) invalidate_jvmti_stack(_thread)); + JVMTI_ONLY(invalidate_jvmti_stack(_thread)); _thread->set_cont_fastpath(_fastpath);
03-09-2024
With the updates I am making to this test for JDK-8324868 (and also some debug agent changes), it now gets this assert on every run. The stack trace seems to always show the JVMTI upcall to Thread.interrupt(). This is the result of the debug agent encountering an interrupt while handling an event (see cbSingleStep() in the stack trace below), and then having to call JVMTI InterruptThread(), which does the java upcall. Current thread (0x00007fc398403190): JavaThread "ForkJoinPool-1-worker-1" daemon [_thread_in_vm, id=1176934, stack(0x00007fc367cfe000,0x00007fc367dfe000) (1024K)], _nested_threads_hazard_ptr_cnt=0 Stack: [0x00007fc367cfe000,0x00007fc367dfe000], sp=0x00007fc367dfb8a0, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11e8317] JvmtiThreadState::cur_stack_depth()+0xf7 (jvmtiThreadState.cpp:867) V [libjvm.so+0x11a8b21] JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0xa1 (jvmtiExport.cpp:1929) V [libjvm.so+0x11ab4d9] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x249 (jvmtiExport.cpp:1896) V [libjvm.so+0xe72017] InterpreterRuntime::post_method_exit(JavaThread*)+0x77 (interpreterRuntime.cpp:1253) j java.lang.Thread.setInterrupt()V+16 java.base@23-internal j java.lang.VirtualThread.interrupt()V+106 java.base@23-internal v ~StubRoutines::call_stub 0x00007fc388172d21 V [libjvm.so+0xe8fe19] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4a9 (javaCalls.cpp:415) V [libjvm.so+0xe904d5] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x345 (javaCalls.cpp:329) V [libjvm.so+0xe906f6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76 (javaCalls.cpp:191) V [libjvm.so+0x117c724] JvmtiEnv::InterruptThread(_jobject*)+0x234 (jvmtiEnv.cpp:1236) V [libjvm.so+0x112eabb] jvmti_InterruptThread+0x18b (jvmtiEnter.cpp:811) C [libjdwp.so+0x27667] threadControl_onEventHandlerExit+0xe7 (threadControl.c:2128) C [libjdwp.so+0x1a974] cbSingleStep+0xd4 (eventHandler.c:750) V [libjvm.so+0x11aba74] JvmtiExport::post_single_step(JavaThread*, Method*, unsigned char*)+0x204 (jvmtiExport.cpp:1991) V [libjvm.so+0x11abcba] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0xaa (jvmtiExport.cpp:1335) V [libjvm.so+0xe715f8] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1147) j java.lang.invoke.LambdaForm$MH+0x00007fc327004000.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+36 java.base@23-internal J 3423 jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base@23-internal (0 bytes) @ 0x00007fc388bbb453 [0x00007fc388bbb2e0+0x0000000000000173] J 3435 c2 jdk.internal.vm.Continuation.run()V java.base@23-internal (586 bytes) @ 0x00007fc388bc1e7c [0x00007fc388bc1940+0x000000000000053c] J 3422 c2 java.lang.VirtualThread.runContinuation()V java.base@23-internal (132 bytes) @ 0x00007fc388bbb8d4 [0x00007fc388bbb7e0+0x00000000000000f4] J 3420 c2 java.lang.VirtualThread$$Lambda+0x00007fc32704afa8.run()V java.base@23-internal (8 bytes) @ 0x00007fc388bbaf10 [0x00007fc388bbaec0+0x0000000000000050] J 3922 c2 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute()Ljava/lang/Void; java.base@23-internal (11 bytes) @ 0x00007fc388c33734 [0x00007fc388c336c0+0x0000000000000074] J 3416 c2 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute()Ljava/lang/Object; java.base@23-internal (5 bytes) @ 0x00007fc388bba864 [0x00007fc388bba820+0x0000000000000044] J 4567 c1 java.util.concurrent.ForkJoinTask$InterruptibleTask.exec()Z java.base@23-internal (84 bytes) @ 0x00007fc38165d9ac [0x00007fc38165d420+0x000000000000058c] J 4563 c1 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;I)V java.base@23-internal (93 bytes) @ 0x00007fc38165c1f4 [0x00007fc38165bf40+0x00000000000002b4] J 4519 c2 java.util.concurrent.ForkJoinPool.scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;JI)J java.base@23-internal (301 bytes) @ 0x00007fc388c69324 [0x00007fc388c69100+0x0000000000000224] j java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+62 java.base@23-internal J 3381 c1 java.util.concurrent.ForkJoinWorkerThread.run()V java.base@23-internal (180 bytes) @ 0x00007fc3813bf344 [0x00007fc3813bf0e0+0x0000000000000264] v ~StubRoutines::call_stub 0x00007fc388172d21 V [libjvm.so+0xe8fe19] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4a9 (javaCalls.cpp:415) V [libjvm.so+0xe904d5] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x345 (javaCalls.cpp:329) V [libjvm.so+0xe906f6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76 (javaCalls.cpp:191) V [libjvm.so+0xffb493] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2937) V [libjvm.so+0xec569c] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:723) V [libjvm.so+0x17b2706] Thread::call_run()+0xb6 (thread.cpp:221) V [libjvm.so+0x14b90a7] thread_native_entry(Thread*)+0x127 (os_linux.cpp:817)
22-02-2024
Possibly the same issue as JDK-8043571
01-05-2023