Parallel GC Thread crash

Sundara Mohan M m.sundar85 at
Tue Feb 4 03:38:46 UTC 2020

   I am seeing following crashes frequently on our servers
# A fatal error has been detected by the Java Runtime Environment:
#  SIGSEGV (0xb) at pc=0x00007fca3281d311, pid=103575, tid=108299
# JRE version: OpenJDK Runtime Environment (13.0.1+9) (build 13.0.1+9)
# Java VM: OpenJDK 64-Bit Server VM (13.0.1+9, mixed mode, tiered, parallel
gc, linux-amd64)
# Problematic frame:
# V  []  PCMarkAndPushClosure::do_oop(oopDesc**)+0x51
# No core dump will be written. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
# If you would like to submit a bug report, please visit:

---------------  T H R E A D  ---------------

Current thread (0x00007fca2c051000):  GCTaskThread "ParGC Thread#8" [stack:
0x00007fca30277000,0x00007fca30377000] [id=108299]

Stack: [0x00007fca30277000,0x00007fca30377000],  sp=0x00007fca30374890,
 free space=1014k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V  []  PCMarkAndPushClosure::do_oop(oopDesc**)+0x51
V  []  OopMapSet::oops_do(frame const*, RegisterMap
const*, OopClosure*)+0x2eb
V  []  frame::oops_do_internal(OopClosure*,
CodeBlobClosure*, RegisterMap*, bool)+0x99
V  []  JavaThread::oops_do(OopClosure*,
V  []  ThreadRootsMarkingTask::do_it(GCTaskManager*,
unsigned int)+0xb0
V  []  GCTaskThread::run()+0x1eb
V  []  Thread::call_run()+0x10d
V  []  thread_native_entry(Thread*)+0xe7

JavaThread 0x00007fb85c004800 (nid = 111387) was being processed
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::_new_array_Java
J 225122 c2
(207 bytes) @ 0x00007fca21f1a5d8 [0x00007fca21f17f20+0x00000000000026b8]
J 62342 c2 webservice.exception.ExceptionLoggingWrapper.execute()V (1004
bytes) @ 0x00007fca20f0aec8 [0x00007fca20f07f40+0x0000000000002f88]
J 225129 c2
(105 bytes) @ 0x00007fca1da512ac [0x00007fca1da51100+0x00000000000001ac]
J 131643 c2
(9 bytes) @ 0x00007fca20ce6190 [0x00007fca20ce60c0+0x00000000000000d0]
J 55114 c2
(332 bytes) @ 0x00007fca2051fe64 [0x00007fca2051f820+0x0000000000000644]
J 57859 c2 webservice.filters.ResponseSerializationWorker.execute()Z (272
bytes) @ 0x00007fca1ef2ed18 [0x00007fca1ef2e140+0x0000000000000bd8]
J 16114% c2;
(486 bytes) @ 0x00007fca1ced465c [0x00007fca1ced4200+0x000000000000045c]
J 11639 c2 java.base at 13.0.1 (123
bytes) @ 0x00007fca1cd00858 [0x00007fca1cd007c0+0x0000000000000098]
J 7560 c1
java.base at 13.0.1 (187 bytes) @ 0x00007fca15b23f54
J 5143 c1 java.util.concurrent.ThreadPoolExecutor$
java.base at 13.0.1 (9 bytes) @ 0x00007fca15b39abc
J 4488 c1 java.base at 13.0.1 (17 bytes) @
0x00007fca159fc174 [0x00007fca159fc040+0x0000000000000134]
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr:

Register to memory mapping:

Can someone shed more info on when this can happen? I am seeing this on
multiple servers with Java 13.0.1+9 on RHEL6 servers.

There was another thread in hotspot runtime where David Holmes pointed this
> siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr:

> This seems it may be related to:

Just wondering if this is same or something to do with GC specific.


More information about the hotspot-gc-dev mailing list