The test runtime/handshake/MixedHandshakeWalkStackTest.java might crash if run with JFR.
The stacktrace shows the problem. The test starts a handshake which makes allocation. This handshake is executed on the thread which is doing some jfr work with NoHandleMark. Similar handshakes are used in getStacktrace jvmti function. So it might cause similar issues in jvmti agents as in this test.
The stack:
V [libjvm.so+0xda1354] HandleArea::allocate_handle(oop)+0x234 (handles.cpp:40)
V [libjvm.so+0x6fbb20] Handle::Handle(Thread*, oop)+0x80 (handles.inline.hpp:42)
V [libjvm.so+0xe9124e] java_lang_Throwable::print_stack_element(outputStream*, Method*, int)+0x7e (javaClasses.cpp:2423)
V [libjvm.so+0xec0c35] JavaThread::print_stack_on(outputStream*)+0x135 (javaThread.cpp:1744)
V [libjvm.so+0x18bc92f] WB_HandshakeWalkStack::TraceSelfClosure::do_thread(Thread*)+0x7f (whitebox.cpp:2237)
V [libjvm.so+0xda44e6] HandshakeOperation::do_handshake(JavaThread*)+0x46 (handshake.cpp:326)
V [libjvm.so+0xda46e9] HandshakeState::process_by_self(bool, bool)+0x139 (handshake.cpp:571)
V [libjvm.so+0x15eef77] SafepointMechanism::process(JavaThread*, bool, bool)+0x47 (safepointMechanism.cpp:159)
V [libjvm.so+0xf36a7c] JfrPostBox::synchronous_post(int)+0x3bc (safepointMechanism.inline.hpp:83)
V [libjvm.so+0xf096e8] jfr_flush+0x68 (jfrJniMethod.cpp:302)
j jdk.jfr.internal.JVM.flush()V+0 jdk.jfr@22-internal
j jdk.jfr.internal.MetadataRepository.flush()V+11 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.FlushTask.execute(JLjdk/jfr/internal/periodic/PeriodicType;)V+3 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicTask.run(JLjdk/jfr/internal/periodic/PeriodicType;)V+15 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicEvents.doPeriodic()J+327 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.periodicTask()V+47 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.lambda$startDiskMonitor$1()V+1 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder$$Lambda+0x00007f00b70429c8.run()V+4 jdk.jfr@22-internal
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@22-internal
j java.lang.Thread.run()V+19 java.base@22-internal
v ~StubRoutines::call_stub 0x00007f011808bd21
V [libjvm.so+0xe84c4f] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x47f (javaCalls.cpp:415)
V [libjvm.so+0xe852a1] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x331 (javaCalls.cpp:329)
V [libjvm.so+0xe854b5] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x75 (javaCalls.cpp:191)
V [libjvm.so+0xfe13c3] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2937)
V [libjvm.so+0xeba2cc] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:720)
V [libjvm.so+0x17a1a3a] Thread::call_run()+0xba (thread.cpp:220)
V [libjvm.so+0x14a68ea] thread_native_entry(Thread*)+0x12a (os_linux.cpp:785)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j jdk.jfr.internal.JVM.flush()V+0 jdk.jfr@22-internal
j jdk.jfr.internal.MetadataRepository.flush()V+11 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.FlushTask.execute(JLjdk/jfr/internal/periodic/PeriodicType;)V+3 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicTask.run(JLjdk/jfr/internal/periodic/PeriodicType;)V+15 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicEvents.doPeriodic()J+327 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.periodicTask()V+47 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.lambda$startDiskMonitor$1()V+1 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder$$Lambda+0x00007f00b70429c8.run()V+4 jdk.jfr@22-internal
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@22-internal
j java.lang.Thread.run()V+19 java.base@22-internal
v ~StubRoutines::call_stub 0x00007f011808bd21
The stacktrace shows the problem. The test starts a handshake which makes allocation. This handshake is executed on the thread which is doing some jfr work with NoHandleMark. Similar handshakes are used in getStacktrace jvmti function. So it might cause similar issues in jvmti agents as in this test.
The stack:
V [libjvm.so+0xda1354] HandleArea::allocate_handle(oop)+0x234 (handles.cpp:40)
V [libjvm.so+0x6fbb20] Handle::Handle(Thread*, oop)+0x80 (handles.inline.hpp:42)
V [libjvm.so+0xe9124e] java_lang_Throwable::print_stack_element(outputStream*, Method*, int)+0x7e (javaClasses.cpp:2423)
V [libjvm.so+0xec0c35] JavaThread::print_stack_on(outputStream*)+0x135 (javaThread.cpp:1744)
V [libjvm.so+0x18bc92f] WB_HandshakeWalkStack::TraceSelfClosure::do_thread(Thread*)+0x7f (whitebox.cpp:2237)
V [libjvm.so+0xda44e6] HandshakeOperation::do_handshake(JavaThread*)+0x46 (handshake.cpp:326)
V [libjvm.so+0xda46e9] HandshakeState::process_by_self(bool, bool)+0x139 (handshake.cpp:571)
V [libjvm.so+0x15eef77] SafepointMechanism::process(JavaThread*, bool, bool)+0x47 (safepointMechanism.cpp:159)
V [libjvm.so+0xf36a7c] JfrPostBox::synchronous_post(int)+0x3bc (safepointMechanism.inline.hpp:83)
V [libjvm.so+0xf096e8] jfr_flush+0x68 (jfrJniMethod.cpp:302)
j jdk.jfr.internal.JVM.flush()V+0 jdk.jfr@22-internal
j jdk.jfr.internal.MetadataRepository.flush()V+11 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.FlushTask.execute(JLjdk/jfr/internal/periodic/PeriodicType;)V+3 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicTask.run(JLjdk/jfr/internal/periodic/PeriodicType;)V+15 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicEvents.doPeriodic()J+327 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.periodicTask()V+47 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.lambda$startDiskMonitor$1()V+1 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder$$Lambda+0x00007f00b70429c8.run()V+4 jdk.jfr@22-internal
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@22-internal
j java.lang.Thread.run()V+19 java.base@22-internal
v ~StubRoutines::call_stub 0x00007f011808bd21
V [libjvm.so+0xe84c4f] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x47f (javaCalls.cpp:415)
V [libjvm.so+0xe852a1] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x331 (javaCalls.cpp:329)
V [libjvm.so+0xe854b5] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x75 (javaCalls.cpp:191)
V [libjvm.so+0xfe13c3] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2937)
V [libjvm.so+0xeba2cc] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:720)
V [libjvm.so+0x17a1a3a] Thread::call_run()+0xba (thread.cpp:220)
V [libjvm.so+0x14a68ea] thread_native_entry(Thread*)+0x12a (os_linux.cpp:785)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j jdk.jfr.internal.JVM.flush()V+0 jdk.jfr@22-internal
j jdk.jfr.internal.MetadataRepository.flush()V+11 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.FlushTask.execute(JLjdk/jfr/internal/periodic/PeriodicType;)V+3 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicTask.run(JLjdk/jfr/internal/periodic/PeriodicType;)V+15 jdk.jfr@22-internal
j jdk.jfr.internal.periodic.PeriodicEvents.doPeriodic()J+327 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.periodicTask()V+47 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder.lambda$startDiskMonitor$1()V+1 jdk.jfr@22-internal
j jdk.jfr.internal.PlatformRecorder$$Lambda+0x00007f00b70429c8.run()V+4 jdk.jfr@22-internal
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@22-internal
j java.lang.Thread.run()V+19 java.base@22-internal
v ~StubRoutines::call_stub 0x00007f011808bd21
- relates to
-
JDK-8317262 LockStack::contains(oop) fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"
- Resolved