guarantee(object->mark() == markWord::INFLATING()) failed: invariant

[Daniel D. Daugherty]

Thanks for filing the bug!

Dan


On 10/2/20 6:12 AM, Doerr, Martin wrote:
> Hi Dan,
>
> I just filed
> https://bugs.openjdk.java.net/browse/JDK-8253927
>
> I'll also look into the code, but this looks like a difficult problem.
>
> Best regards,
> Martin
>
>
>> -----Original Message-----
>> From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
>> Sent: Donnerstag, 1. Oktober 2020 22:29
>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed:
>> invariant
>>
>> Hi Martin,
>>
>> It's best to file a new bug and make it clear that the sighting is on
>> PPC. I have not seen this failure mode in my own stress testing nor
>> have I seen it in Mach5...
>>
>> Dan
>>
>>
>> On 10/1/20 2:52 PM, Doerr, Martin wrote:
>>> Hi,
>>>
>>> we have seen a crash when running Spec JVM 2008 on a Power9 machine.
>>> It occurred only once so I can't tell if it is a PPC64 specific or weak memory
>> model specific issue.
>>> Locking code has worked very solid for many years on this platform.
>>>
>>> #  Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363
>>> #  guarantee(object->mark() == markWord::INFLATING()) failed: invariant
>>>
>>> V  [libjvm.so+0xe463cc]  ObjectSynchronizer::inflate(Thread*, oopDesc*,
>> ObjectSynchronizer::InflateCause)+0x76c
>>> V  [libjvm.so+0xe467ac]  ObjectSynchronizer::exit(oopDesc*, BasicLock*,
>> Thread*)+0x4c
>>> V  [libjvm.so+0xda18a0]
>> SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*,
>> JavaThread*)+0xc0
>>> J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1-
>> internal (42 bytes) @ 0x00007fff95e1d84c
>> [0x00007fff95e1d400+0x000000000000044c]
>>> J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V
>> java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0
>> [0x00007fff95f1ea80+0x0000000000000720]
>>> J 6534 c1
>> spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretK
>> ey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794
>> [0x00007fff8e574e00+0x0000000000000994]
>>> j  spec.benchmarks.crypto.aes.Main.harnessMain()V+69
>>> ...
>>>
>>> object->_mark points to a stack lock:
>>> 0x00007ffe67dfdbc8 is pointing into the stack for thread:
>> 0x00007ffeec10d5e0
>>> content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009
>>> which belongs to the crashing thread:
>>> Current thread (0x00007ffeec10d5e0):  JavaThread "BenchmarkThread
>> crypto.aes 5" [_thread_in_Java, id=19363,
>> stack(0x00007ffe67c00000,0x00007ffe67e00000)]
>>> I wonder how this can happen. Can it be related to asynchronous lock
>> deflation?
>>> Any ideas are welcome.
>>>
>>> Best regards,
>>> Martin
>>>