If using internal events like EventValue and starting JFR recording no other events the VM crashes due to an uninitialized value with the folowing stacktrace:
Current thread (0x00007fda08218cb0): JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=1046593, stack(0x00007fd9790e5000,0x00007fd9791e6000) (1028K)]
Stack: [0x00007fd9790e5000,0x00007fd9791e6000], sp=0x00007fd9791e4a40, free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xe907ed] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, JavaThread*)+0x1d (symbol.hpp:140)
V [libjvm.so+0x98d7f6] JfrUpcalls::unhide_internal_types(JavaThread*)+0x36 (systemDictionary.hpp:94)
V [libjvm.so+0x93e28a] JfrMetadataEvent::write(JfrChunkWriter&)+0x4ba (jfrMetadataEvent.cpp:49)
V [libjvm.so+0x961c36] JfrRecorderService::post_safepoint_write()+0x96 (jfrRecorderService.cpp:374)
V [libjvm.so+0x962746] JfrRecorderService::rotate(int)+0xa6 (jfrRecorderService.cpp:573)
V [libjvm.so+0x9631d1] recorderthread_entry(JavaThread*, JavaThread*)+0x111 (jfrRecorderThreadLoop.cpp:81)
V [libjvm.so+0x9055d8] JavaThread::thread_main_inner() [clone .part.0]+0xb8 (javaThread.cpp:758)
V [libjvm.so+0xed240f] Thread::call_run()+0x9f (thread.cpp:225)
V [libjvm.so+0xcf0e45] thread_native_entry(Thread*)+0xd5 (os_linux.cpp:858)
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000004
This can be easily reproduced by applying:
---
diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
index ea18ff3a006..67e01c390bd 100644
--- a/src/hotspot/share/runtime/threads.cpp
+++ b/src/hotspot/share/runtime/threads.cpp
@@ -827,6 +827,8 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
ClassLoader::print_counters(&log);
}
+ EventValue e;
+ e.commit(4711);
return JNI_OK;
}
---
And running:
$ java -XX:StartFlightRecording:settings=none -version
The uninitialized value is jvm_upcalls_class_sym which is never initialized in JfrUpcalls because no other events trigger the initialization. This has likely never happened in the past when some code was always instrumented in the JDK.
Current thread (0x00007fda08218cb0): JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=1046593, stack(0x00007fd9790e5000,0x00007fd9791e6000) (1028K)]
Stack: [0x00007fd9790e5000,0x00007fd9791e6000], sp=0x00007fd9791e4a40, free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xe907ed] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, JavaThread*)+0x1d (symbol.hpp:140)
V [libjvm.so+0x98d7f6] JfrUpcalls::unhide_internal_types(JavaThread*)+0x36 (systemDictionary.hpp:94)
V [libjvm.so+0x93e28a] JfrMetadataEvent::write(JfrChunkWriter&)+0x4ba (jfrMetadataEvent.cpp:49)
V [libjvm.so+0x961c36] JfrRecorderService::post_safepoint_write()+0x96 (jfrRecorderService.cpp:374)
V [libjvm.so+0x962746] JfrRecorderService::rotate(int)+0xa6 (jfrRecorderService.cpp:573)
V [libjvm.so+0x9631d1] recorderthread_entry(JavaThread*, JavaThread*)+0x111 (jfrRecorderThreadLoop.cpp:81)
V [libjvm.so+0x9055d8] JavaThread::thread_main_inner() [clone .part.0]+0xb8 (javaThread.cpp:758)
V [libjvm.so+0xed240f] Thread::call_run()+0x9f (thread.cpp:225)
V [libjvm.so+0xcf0e45] thread_native_entry(Thread*)+0xd5 (os_linux.cpp:858)
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000004
This can be easily reproduced by applying:
---
diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
index ea18ff3a006..67e01c390bd 100644
--- a/src/hotspot/share/runtime/threads.cpp
+++ b/src/hotspot/share/runtime/threads.cpp
@@ -827,6 +827,8 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
ClassLoader::print_counters(&log);
}
+ EventValue e;
+ e.commit(4711);
return JNI_OK;
}
---
And running:
$ java -XX:StartFlightRecording:settings=none -version
The uninitialized value is jvm_upcalls_class_sym which is never initialized in JfrUpcalls because no other events trigger the initialization. This has likely never happened in the past when some code was always instrumented in the JDK.
- links to
-
Commit(master) openjdk/jdk/21d1e4d8
-
Review(master) openjdk/jdk/20676