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

Doerr, Martin martin.doerr at sap.com
Thu Oct 15 09:05:48 UTC 2020


Hi Thomas,

thanks for your hints. I had replied in the bug only and attached the hs_err file (not sure if you have seen it):
https://bugs.openjdk.java.net/browse/JDK-8253927

I'm glad https://bugs.openjdk.java.net/browse/JDK-8254164 is fixed, but it's very unclear to me if the crash was caused by that.
To me, it looks more like another thread has deflated the monitor which is not allowed. I don't know if this could be caused by the GC issue.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> On Behalf Of Thomas Schatzl
> Sent: Donnerstag, 8. Oktober 2020 10:31
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed:
> invariant
> 
> Hi Martin,
> 
> On 01.10.20 20:52, 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.
> >
> 
> This reminds me a bit of JDK-8248438 because of the stack trace. This
> will be fixed by JDK-8254164.
> 
> You can you check whether its the same issue using the following keys:
> 
> Using g1 (the snippet does not show even that)
> - the markword contains a self-forwarded pointer
> AND/OR
> - the most recent gc has been a mixed gc with an optional evacuation
> phase and an evacuation failure (can be seen in a gc log)
> 
> If you can manage to verify the first, this is a duplicate of
> JDK-8254164 (note that that bug is there since JDK 13). If you can only
> verify the latter, there is very high probability that this is the issue.
> 
> Thanks,
>    Thomas


More information about the hotspot-runtime-dev mailing list