fatal error: must own lock Threads_lock
Doerr, Martin
martin.doerr at sap.com
Tue Mar 31 11:59:47 UTC 2020
Hi Dan,
we have observed the error (see subject) when running jck test
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
on Windows.
Stack:
V [jvm.dll+0x413e10] report_fatal+0x80 (debug.cpp:286)
V [jvm.dll+0x990eb6] assert_locked_or_safepoint_or_handshake+0xf6 (mutexlocker.cpp:194)
V [jvm.dll+0xc14d95] JavaThread::get_thread_name+0x85 (thread.cpp:3191)
V [jvm.dll+0x17c07] Thread::stack_end+0x27 (thread.hpp:762)
V [jvm.dll+0xc160e1] JavaThread::is_lock_owned+0x21 (thread.cpp:2246)
V [jvm.dll+0xc17cf4] Threads::owning_thread_from_monitor_owner+0x74 (thread.cpp:4752)
V [jvm.dll+0x7e6d43] JvmtiEnvBase::get_object_monitor_usage+0x1e3 (jvmtienvbase.cpp:996)
V [jvm.dll+0x7ddc2c] JvmtiEnv::GetObjectMonitorUsage+0x4c (jvmtienv.cpp:2870)
V [jvm.dll+0x7ad650] jvmti_GetObjectMonitorUsage+0x130 (jvmtienter.cpp:4105)
C [jckjvmti.dll+0x3a56a]
Threads_lock was taken before the following change:
8167108: inconsistent handling of SR_lock can lead to crashes
Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism.
http://hg.openjdk.java.net/jdk/jdk/rev/8d15b1369c7a
I guess we need to add it back.
Should I create an issue for that?
Best regards,
Martin
More information about the hotspot-runtime-dev
mailing list