JDK-8330146 : assert(!_thread->is_in_any_VTMS_transition()) failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 21,22,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-04-12
  • Updated: 2024-08-12
  • Resolved: 2024-05-09
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 21 JDK 23
21.0.5Fixed 23 b23Fixed
Related Reports
Duplicate :  
JDK-8329140 - Spring boot virtual threads -Djdk.tracePinnedThreads=full causes tasks to hang
Relates :  
JDK-8329140 - Spring boot virtual threads -Djdk.tracePinnedThreads=full causes tasks to hang
Relates :  
JDK-8337331 - crash: pinned virtual thread will lead to jvm crash when running with the javaagent option
Description
I was running jdk/java/lang/Thread/virtual/TracePinnedThreads.java with javaagent performing some instrumentation, and the test crashed with this assertion:

#  Internal Error (/home/rvansa/work/jdk/src/hotspot/share/prims/jvmtiExport.cpp:932), pid=398299, tid=398333
#  assert(!_thread->is_in_any_VTMS_transition()) failed: CFLH events are not allowed in any VTMS transition
#
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.rvansa.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.rvansa.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x11e1dbf]  JvmtiExport::post_class_file_load_hook(Symbol*, Handle, Handle, unsigned char**, unsigned char**, JvmtiCachedClassFileData**)+0x39f
Comments
[jdk21u-fix-request] Approval Request from Jiawei Tang fix bugs for jdk21. It's a clean backport. After this, I will backport [JDK-8337331](https://bugs.openjdk.org/browse/JDK-8337331) to fix the problem completely.
09-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/907 Date: 2024-08-09 07:20:29 +0000
09-08-2024
Hi, actually, this problem affects jdk21, I want to backport it and https://bugs.openjdk.org/browse/JDK-8337331 to fix it.
09-08-2024
I provisionally put 21, 22 as affected versions, as we would expect users to reach for this diagnostic option sometimes. It is not yet clear to me if the same bug affects JDK 21.
13-05-2024
Changeset: c4ff58b9 Author: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2024-05-09 14:30:15 +0000 URL: https://git.openjdk.org/jdk/commit/c4ff58b9bcfd08eae0623a648a837e08f25b3f9b
09-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/19054 Date: 2024-05-02 10:07:35 +0000
02-05-2024
Okay. Thanks, Alan. My plan is to replace this assert with a conditional return in case when the attempt to post the event is in a context of VTMS transition. This impacts three kinds of events: CFLH, ClassPrepare and ClassLoad. This will align these events kinds with all other events. The assert was added in these 3 cases with the intention to identify all cases when with attempts to do class loading while in VTMS transitions.
02-05-2024
The debugging property jdk.tracePinnedThreads is a left over from early development in the loom repo. We probably shouldn't have brought it into the main line in JDK 19. There are several issues with it, and has been removed in the loom repo as part of the big update for object monitors. For this JBS issue then I think it's the onPinned callback loading PinnedThreadPrinter (VThreadContinuation is already loaded). A workaround would be to preload this class, or use JFR events instead of -Djdk.tracePinnedThreads=full.
25-04-2024
The VThreadContinuation.onPinned() is invoked in the context of an unmount transition. Please, see this function: /** * Invokes Continuation.yield, notifying JVMTI (if enabled) to hide frames until * the continuation continues. */ @Hidden private boolean yieldContinuation() { notifyJvmtiUnmount(/*hide*/true); <= JVMTI is notified about unmount transition start try { return Continuation.yield(VTHREAD_SCOPE); } finally { notifyJvmtiMount(/*hide*/false); <= JVMTI is notified about unmount transition finish } } This the most important part of the stack trace: # Internal Error (/home/rvansa/work/jdk/src/hotspot/share/prims/jvmtiExport.cpp:932), pid=398299, tid=398333 # assert(!_thread->is_in_any_VTMS_transition()) failed: CFLH events are not allowed in any VTMS transition . . . . --------------- T H R E A D --------------- Current thread (0x00007035f88840e0): JavaThread "ForkJoinPool-1-worker-1" daemon [_thread_in_vm, id=398333, stack(0x00007036a8ef1000,0x00007036a8ff1000) (1024K)] Stack: [0x00007036a8ef1000,0x00007036a8ff1000], sp=0x00007036a8fedca0, free space=1011k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11e1dbf] JvmtiExport::post_class_file_load_hook(Symbol*, Handle, Handle, unsigned char**, unsigned char**, JvmtiCachedClassFileData**)+0x39f (jvmtiExport.cpp:932) V [libjvm.so+0x1236049] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0x719 (klassFactory.cpp:148) V [libjvm.so+0x996c3e] ClassLoader::load_class(Symbol*, PackageEntry*, bool, JavaThread*)+0x1ee (classLoader.cpp:1168) V [libjvm.so+0x18d0414] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x444 (systemDictionary.cpp:1279) V [libjvm.so+0x18ce3c0] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x20 (systemDictionary.cpp:1343) V [libjvm.so+0x18ced73] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, JavaThread*)+0x813 (systemDictionary.cpp:702) V [libjvm.so+0x18cf4a6] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, JavaThread*)+0x26 (systemDictionary.cpp:321) V [libjvm.so+0xa5e491] ConstantPool::klass_at_impl(constantPoolHandle const&, int, JavaThread*)+0x181 (constantPool.cpp:550) V [libjvm.so+0xa613d6] ConstantPool::klass_ref_at(int, Bytecodes::Code, JavaThread*)+0x66 (constantPool.hpp:389) V [libjvm.so+0x12854d1] LinkInfo::LinkInfo(constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0x61 (linkResolver.cpp:250) V [libjvm.so+0x128b6ad] LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x2d (linkResolver.cpp:1666) V [libjvm.so+0x128e8e0] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0xb0 (linkResolver.cpp:1626) V [libjvm.so+0xea0b26] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x326 (interpreterRuntime.cpp:853) V [libjvm.so+0xea18fb] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xdb (interpreterRuntime.cpp:981) j java.lang.VirtualThread$VThreadContinuation.onPinned(Ljdk/internal/vm/Continuation$Pinned;)V+42 java.base@23-internal j jdk.internal.vm.Continuation.onPinned0(I)V+5 java.base@23-internal j jdk.internal.vm.Continuation.yield0(Ljdk/internal/vm/ContinuationScope;Ljdk/internal/vm/Continuation;)Z+325 java.base@23-internal j jdk.internal.vm.Continuation.yield(Ljdk/internal/vm/ContinuationScope;)Z+69 java.base@23-internal j java.lang.VirtualThread.yieldContinuation()Z+8 java.base@23-internal j java.lang.VirtualThread.parkNanos(J)V+64 java.base@23-internal So, it seems the VThreadContinuation class is being loaded when in the unmount transition. This caused posting a CFLH event. Current implementation does not allow any events to be posted in transitions as the details provided to the JVMTI agent (to the event callback) can be inconsistent. For instance, the thread identity can be wrong. We currently have this assert in place which helps to identify places where do class loading in VTMS transition context. It is not clear yet what fix would be better for this issue. The best approach is to avoid class loading in transition contexts. But it is up to the VirtualThread class implementation. Another approach would be to remove relax this assert and silently ignore such CFLH events. Need to consult with the Core team first. [~alanb] Alan, what do you think about the potential approaches above to fix this issue?
25-04-2024