Java crash in GCTaskThread with Shenandoah collector

Solution Verified - Updated

Environment

  • OpenJDK
    • OpenJDK 8
    • OpenJDK 11
  • Red Hat Enterprise Linux (RHEL)
    • RHEL 6
    • RHEL 7

Issue

  • Java application crashes with the Shenandoah collector and the following in the fatal error log:
#  SIGSEGV (0xb) at pc=0x00007f32900f8a10, pid=10797, tid=0x00007f328dae5700
...
# Problematic frame:
# V  [libjvm.so+0xa41a10]
...
Current thread (0x00007f3288064040):  GCTaskThread [stack: 0x00007f328d9e5000,0x00007f328dae6000] [id=10828]

Root Cause

Crashes during the heap walk by GC can be an indication of memory hardware failure, see Diagnostics Steps to get more data and verify hardware issue(s).

Other known causes for issues when Shenandoah is executing GCTaskThread:

Diagnostic Steps

  1. Add the the following JVM options to enable heap verification during garbage collection:
-XX:+UnlockDiagnosticVMOptions -XX:+ShenandoahVerify

This will enable a number of checks to verify heap consistency (e.g. all references are good) and output details in the gc logging.

The functionality is available on releases and fastdebug builds. If Verifier identifies a problem, it is most likely a Shenandoah GC bug.

The Verifier is single threaded, requires safepoints, and is resource intensive (it traverses the entire heap). It will impact throughput and latency and should be avoided on critical workloads.

  1. Run memtest: How to check if system RAM is faulty in Red Hat Enterprise Linux?.

Crashes during the heap walk by GC can indicate a memory hardware issue.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.