fatal error: must own lock Threads_lock

[David Holmes]

Correction at end ...

On 31/03/2020 10:13 pm, David Holmes wrote:
> 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

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

David
-----

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