guarantee(l_om_in_use_count == in_use_count) failed

[Daniel D. Daugherty]

Hi Martin,

Sorry for the delay in responding. I was out of the office for a couple
of days at the end of last week.

I haven't seen that guarantee() failure in any of my testing nor in any
of the many, many Mach5 runs that the fix for 8153224 has been thru.
Thanks for filing the bug!

Hi David,

Thanks for fielding the query while I was out of the office.


I'll take a look at the bug later today.

Dan


On 6/5/20 5:49 AM, Doerr, Martin wrote:
> Hi David,
>
> thanks for your quick reply.
> I've filed https://bugs.openjdk.java.net/browse/JDK-8246676
>
> Unfortunately, I don't have much information and no reproducer.
> But there may be a chance to find it by reading code.
>
> I'll check my emails next week though I'm on vacation (I'll be really out afterwards).
>
> Best regards,
> Martin
>
>
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Freitag, 5. Juni 2020 03:54
>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: guarantee(l_om_in_use_count == in_use_count) failed
>>
>> Hi Martin,
>>
>> That is a new assertion that is failing, relating to the async monitor
>> deflation logic - JDK-8153224 - as you surmised.
>>
>> We haven't seen any failures of this kind that I am aware of.
>>
>> Please file a bug and assign to Dan (dcubed).
>>
>> Thanks,
>> David
>>
>> On 5/06/2020 3:22 am, Doerr, Martin wrote:
>>> Hi,
>>>
>>> I've seen the following guarantee on PPC64le when a thread was about to
>> exit:
>>> #  Internal Error (synchronizer.cpp:1677), pid=47037, tid=47409
>>> #  guarantee(l_om_in_use_count == in_use_count) failed: in-use counts
>> don't match: l_om_in_use_count=2, in_use_count=1
>>> Stack: [0x00003ffe13000000,0x00003ffe13200000],  sp=0x00003ffe131fe180,
>> free space=2040k
>>> Native frames: (J=compiled Java code, A=aot compiled Java code,
>> j=interpreted, Vv=VM code, C=native code)
>>> V  [libjvm.so+0xe5e450]  ObjectSynchronizer::om_flush(Thread*)+0x710
>>> V  [libjvm.so+0xeb0cac]  Threads::remove(JavaThread*, bool)+0x3c
>>> V  [libjvm.so+0xeb6840]  JavaThread::exit(bool,
>> JavaThread::ExitType)+0x830
>>> V  [libjvm.so+0xeb6aa0]  JavaThread::post_run()+0x30
>>> V  [libjvm.so+0xeb3d88]  Thread::call_run()+0x198
>>> V  [libjvm.so+0xcb11d4]  thread_native_entry(Thread*)+0x154
>>> C  [libpthread.so.0+0x8a64]  start_thread+0xf4
>>>
>>> Issue doesn't seem to be reproducible with the proprietary test.
>>> Tip was
>>> http://hg.openjdk.java.net/jdk/jdk/rev/755ab9edca97
>>>
>>> I guess it could be related to
>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>
>>> Is anybody aware of this issue?
>>>
>>> Best regards,
>>> Martin
>>>