fatal error: must own lock Threads_lock

[David Holmes]

Hi Martin,

Sorry for the noise with this one. The new assertion failure masks the 
underlying one which relates to:

  8239895: assert(_stack_base != 0LL) failed: Sanity check

which is out for review right now.


On 31/03/2020 9:59 pm, Doerr, Martin wrote:
> 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.

No, the problem is that I used get_thread_name() in a context that isn't 
supported at the moment. I filed an additional RFE to fix it properly:

https://bugs.openjdk.java.net/browse/JDK-8241043

Cheers,
David
-----

> Should I create an issue for that?
> 
> Best regards,
> Martin
>