JDK-8253389 : bigapps crash in GCTaskThread without caller or stack info
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux,windows
  • CPU: x86_64
  • Submitted: 2020-09-20
  • Updated: 2020-09-23
  • Resolved: 2020-09-23
Related Reports
Duplicate :  
Relates :  
Description
The following test failed in the JDK16 CI:

applications/dacapo/Dacapo24H.java

Here's the crashing thread's info:

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

Current thread (0x00007f11bc00d030):  GCTaskThread "GC Thread#5" [stack: 0x00007f1176eec000,0x00007f1176fec000] [id=28227]

Stack: [0x00007f1176eec000,0x00007f1176fec000],  sp=0x00007f1176feab20,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)

[error occurred during error reporting (printing native stack), id 0xb, SIGSEGV (0xb) at pc=0x00007f121c1487d4]


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000010f5a9cd830


The following test failed in the JDK16 CI:

applications/kitchensink/Kitchensink24HStress.java

Here's the crashing thread's info:

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

Current thread (0x00000131cf0d7600):  GCTaskThread "GC Thread#1" [stack: 0x00000024f9300000,0x00000024f9400000] [id=246044]

Stack: [0x00000024f9300000,0x00000024f9400000],  sp=0x00000024f93ff848,  free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000000000258


siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), data execution prevention violation at address 0x0000000000000258


In both of these tests, we crashed in a GCTaskThread
without even info on the crashing frame. The Dacapo24H.java
failure happened on a Linux-X64 machine and the the
Kitchensink24HStress.java failure happened on a
Win-X64 machine.

I can't remember the last time I got so little information
out of a crash, but I figured I would file a tracking bug
anyway. I'm starting this bug in hotspot/gc for initial triage.
Comments
Closing this bug as a duplicate of the [BACKOUT] is the proper solution so I've changed the duplicates link to: JDK-8253411 [BACKOUT] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs And I've added a relates link to the root cause which is the [REDO] bug: JDK-8249676 [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs The way to think about this is that the failures linked to this bug (JDK-8253389) are resolved by the [BACKOUT] bug so that's why this bug is a duplicate of the [BACKOUT] bug.
23-09-2020