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