JDK-8316538 : runtime/handshake/MixedHandshakeWalkStackTest.java crashes with JFR
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-09-19
  • Updated: 2023-11-02
  • Resolved: 2023-11-02
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 22
22 masterFixed
Related Reports
Relates :  
JDK-8317262 - LockStack::contains(oop) fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"
Description
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
Comments
Changeset: 4f808c62 Author: Markus Grönlund <mgronlun@openjdk.org> Date: 2023-11-02 12:17:18 +0000 URL: https://git.openjdk.org/jdk/commit/4f808c62b0152b634f71c89886ff32650e948b1e
02-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16452 Date: 2023-11-01 14:17:52 +0000
01-11-2023
I think this is a JFR issue. I could not find the exact code that has the NoHandleMark, but this flush code contains code that can lead to a safepoint check and thus execution of an "arbitrary" handshake operation, and so can lead to allocation. If this code path really requires no allocation/handles then it is broken as it allows safepoint checks. So something in the JFR code has to be fixed here: either drop the NHM or else change the code so that it cannot safepoint.
26-09-2023
Is this really a JFR issue?
25-09-2023