JDK-8253295 : bigapps fail due to bad oop in a JavaThread
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-09-17
  • Updated: 2020-09-30
  • Resolved: 2020-09-23
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
The following test failed in the JDK16 CI:

applications/kitchensink/Kitchensink.java

Here's a snippet from the log file:

For random generator using seed: -8404702285129814941
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=-8404702285129814941" to command line.
Stress process main method is started.
[622.439s][warning][gc] GC locker is held; pre-dump GC was skipped
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe9374e160d, pid=13829, tid=13894
#
# JRE version: Java(TM) SE Runtime Environment (16.0+16) (build 16-ea+16-691)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+16-691, mixed mode, sharing, tiered, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x68c60d][thread 13891 also had an error]
  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x5bd
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108732/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e7725095-9551-4bfa-bf1e-76c10af17131/runs/69134796-b815-420f-a6e8-17a7f4bedc1a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.13829)
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108732/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e7725095-9551-4bfa-bf1e-76c10af17131/runs/69134796-b815-420f-a6e8-17a7f4bedc1a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/hs_err_pid13829.log
[thread 13896 also had an error]
[thread 13895 also had an error]
[thread 13897 also had an error]
[thread 13893 also had an error]
[thread 13834 also had an error]
[thread 13892 also had an error]
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(200/19225)----------

Here's the crashing thread's stack:

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

Current thread (0x00007fe4f000bca0):  GCTaskThread "GC Thread#4" [stack: 0x00007fe4ce7e5000,0x00007fe4ce8e5000] [id=13894]

Stack: [0x00007fe4ce7e5000,0x00007fe4ce8e5000],  sp=0x00007fe4ce8e2720,  free space=1013k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x68c60d]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x5bd
V  [libjvm.so+0x6af3bc]  G1ParCopyClosure<(G1Barrier)0, (G1Mark)1>::do_oop(oopDesc**)+0x1fc
V  [libjvm.so+0x70a5fd]  HandleArea::oops_do(OopClosure*)+0x5d
V  [libjvm.so+0xd00488]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x58
V  [libjvm.so+0xd06c07]  Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x187
V  [libjvm.so+0x6b1c33]  G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x73
V  [libjvm.so+0x6b2564]  G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x64
V  [libjvm.so+0x6484d2]  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x22
V  [libjvm.so+0x648f33]  G1EvacuateRegionsBaseTask::work(unsigned int)+0x83
V  [libjvm.so+0xda5e7f]  GangWorker::loop()+0x5f
V  [libjvm.so+0xd084ad]  Thread::call_run()+0xfd
V  [libjvm.so+0xb5bdf7]  thread_native_entry(Thread*)+0xe7


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


Based on this snippet from the thread's stack:

G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x5bd
V  [libjvm.so+0x6af3bc]  G1ParCopyClosure<(G1Barrier)0, (G1Mark)1>::do_oop(oopDesc**)+0x1fc
V  [libjvm.so+0x70a5fd]  HandleArea::oops_do(OopClosure*)+0x5d
V  [libjvm.so+0xd00488]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x58

it looks like we have a bad oop in the JavaThread's handle area.
Starting this bug in hotspot/runtime for initial triage.
Comments
You are right. Thanks for fixing the links.
23-09-2020

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-8253295) are resolved by the [BACKOUT] bug so that's why this bug is a duplicate of the [BACKOUT] bug.
23-09-2020

Looks like a duplicate of JDK-8253081
17-09-2020