Shenandoah crash

Aleksey Shipilev shade at redhat.com
Thu Feb 1 13:53:23 UTC 2018


Thanks for the bug report!

On 02/01/2018 01:05 PM, Lennart Börjeson wrote:
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/Users/lennartb/RaT/openJDK/shenandoah-jdk10/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:184), pid=37194, tid=11267
> #  Error: Shenandoah verification failed; After Mark, Roots: Must be marked in complete bitmap
> 
> Referenced from:
>   interior location: 0x00007faf6cd0d3c0
>   outside of Java heap
>   0x00007faf6cd0d3c0 is a weak global jni handle

                            ^^^^^^^^^^^^^^^^^^^^^^

This one seems enough of the smoking gun to chase the bug for now. It must be the bug in handling
the weak global JNI handles: we apparently miss that root during mark?

If we cannot find any obvious bugs there and/or fail to write a reproducer, we would need to work to
understanding the failing application better. We are going to FOSDEM for the rest of the week, so --
barring heroics of anyone here -- we would be able to look at it next week.

> Time: Thu Feb  1 12:36:33 2018 CET elapsed time: 1471 seconds (0d 0h 24m 31s)

You waited for 24 minutes for this bug to appear, right? I wonder if you can make it more frequent
with -XX:ShenandoahGCHeuristics=aggressive.

> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 10-internal+0-adhoc.lennartb.shenandoah-jdk10)

Also, you don't need fastdebug build to run with -XX:+ShenandoahVerify, and the failure like this
would be caught in release build as well.

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list