JVM crash in oopDesc::size_given_klass with current thread GCTaskThread

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL) 7
    • 7.7
    • 7.8
  • Red Hat build of OpenJDK 8
    • 1.8.0_262-b10
  • Oracle JDK 8
    • 1.8.0_192-b12

Issue

  • The java process (e.g. JBoss) crashes with the following error:
#  SIGSEGV (0xb) at pc=0x00007fe1cdbeb9e1, pid=2613, tid=0x00007fe1bc3b8700
#
# JRE version: OpenJDK Runtime Environment (8.0_262-b10) (build 1.8.0_262-b10)
# Java VM: OpenJDK 64-Bit Server VM (25.262-b10 mixed mode linux-amd64 )
# Problematic frame:
# V  [libjvm.so+0x65a9e1]  oopDesc::size_given_klass(Klass*)+0x1
...
Current thread (0x00005636b0413800):  GCTaskThread [stack: 0x00007fe1bc2b9000,0x00007fe1bc3b9000] [id=2630]
...
Stack: [0x00007fcbcc578000,0x00007fcbcc678000],  sp=0x00007fcbcc676c50,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x645b71]  oopDesc::size_given_klass(Klass*)+0x1
V  [libjvm.so+0x9310dc]  ParScanThreadState::trim_queues(int)+0xfc
V  [libjvm.so+0x9312ca]  ParEvacuateFollowersClosure::do_void()+0x2a
V  [libjvm.so+0x92e4d0]  ParNewGenTask::work(unsigned int)+0x1b0
V  [libjvm.so+0xaef8a8]  GangWorker::loop()+0xd8
V  [libjvm.so+0x90a8b2]  java_start(Thread*)+0x102

  • Using the Concurrent Mark Sweep (CMS) collector (-XX:+UseConcMarkSweepGC).

  • The young generation is full, both the "from" and "to" space are occupied , and there is plenty of free space in the old generation:

Heap:
 par new generation   total 58026688K, used 58026688K [0x00007f8e3cc00000, 0x00007f9ce2c00000, 0x00007f9ce2c00000)
  eden space 54613376K, 100% used [0x00007f8e3cc00000, 0x00007f9b42160000, 0x00007f9b42160000)
  from space 3413312K, 100% used [0x00007f9c126b0000, 0x00007f9ce2c00000, 0x00007f9ce2c00000)
  to   space 3413312K,  99% used [0x00007f9b42160000, 0x00007f9c125c4800, 0x00007f9c126b0000)
 concurrent mark-sweep generation total 288768000K, used 180587371K [0x00007f9ce2c00000, 0x00007fe1bbc00000, 0x00007fe1bbc00000)
 Metaspace       used 389569K, capacity 410421K, committed 779008K, reserved 780288K

Resolution

Consider using a different garbage collector (e.g. G1, Shenandoah, etc.). The CMS collector is deprecated in JDK11 and will be removed altogether in the next Long Term Support (LTS) version, JDK17.

Root Cause

This appears to be a JVM bug that happens when doing a minor collection. When the young generation becomes full, live objects are copied from Eden to the second survivor space, and then live objects are copied from the first survivor space to the second survivor space. If the second survivor space fills and live objects remain in Eden or in the first survivor space, then these objects should be tenured (copied to the old generation). It appears the crash happens when the young generation CMS parallel collector is experiencing retention that requires promoting from the young to the old generation.

Diagnostic Steps

  • Inspect the fatal error log and confirm the issue as described above
  • Test with the latest JDK version.
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.