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