JDK-8224531 : SEGV while collecting Klass statistics
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8,11,13,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-05-21
  • Updated: 2021-10-06
  • Resolved: 2019-07-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14
11.0.5Fixed 13 b29Fixed 14Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Application crashed with

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f103114b6e4, pid=6879, tid=6906
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-ea+0-1090)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-ea+0-1090, mixed mode, sharing, tiered, compressed oops, concurrent mark sweep gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd316e4]  KlassSizeStats::count(oop)+0x34
#
# Core dump will be written. Default location: /scratch/opt/mach5/mesos/work_dir/slaves/df27b84d-b5c1-4760-9e48-df95fd33274c-S108/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f6aa87fe-7c7c-4443-ad15-6e282b313200/runs/33e8a48c-04b2-4a9c-beed-c54e2ea396a1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.6879
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=8 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+IgnoreUnrecognizedVMOptions -XX:MaxRAMPercentage=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/opt/mach5/mesos/work_dir/slaves/df27b84d-b5c1-4760-9e48-df95fd33274c-S108/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f6aa87fe-7c7c-4443-ad15-6e282b313200/runs/33e8a48c-04b2-4a9c-beed-c54e2ea396a1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/java.io.tmpdir -Duser.home=/scratch/opt/mach5/mesos/work_dir/slaves/df27b84d-b5c1-4760-9e48-df95fd33274c-S108/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f6aa87fe-7c7c-4443-ad15-6e282b313200/runs/33e8a48c-04b2-4a9c-beed-c54e2ea396a1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/user.home -agentpath:/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk-13-1090/linux-x64-debug.test/hotspot/jtreg/native/libJvmtiStressModule.so applications.kitchensink.process.stress.Main /scratch/opt/mach5/mesos/work_dir/slaves/df27b84d-b5c1-4760-9e48-df95fd33274c-S108/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f6aa87fe-7c7c-4443-ad15-6e282b313200/runs/33e8a48c-04b2-4a9c-beed-c54e2ea396a1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/kitchensink.final.properties

Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 6 cores, 29G, Oracle Linux Server release 7.1
Time: Tue May 21 19:07:16 2019 UTC elapsed time: 762 seconds (0d 0h 12m 42s)

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

Current thread (0x00007f102c15b000):  VMThread "VM Thread" [stack: 0x00007f100c46f000,0x00007f100c56f000] [id=6906]

Stack: [0x00007f100c46f000,0x00007f100c56f000],  sp=0x00007f100c56d2f0,  free space=1016k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd316e4]  KlassSizeStats::count(oop)+0x34
V  [libjvm.so+0x1127ac5]  Klass::collect_statistics(KlassSizeStats*) const+0x55
V  [libjvm.so+0xdb5fc8]  InstanceKlass::collect_statistics(KlassSizeStats*) const+0x18
V  [libjvm.so+0xd35756]  KlassInfoHisto::print_class_stats(outputStream*, bool, char const*)+0x266
V  [libjvm.so+0xd36e03]  HeapInspection::heap_inspection(outputStream*)+0x783
V  [libjvm.so+0xcd1c46]  VM_GC_HeapInspection::doit()+0x86
V  [libjvm.so+0x177e083]  VM_Operation::evaluate()+0x143
V  [libjvm.so+0x17ad8ff]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.66]+0x17f
V  [libjvm.so+0x17ae3ae]  VMThread::loop()+0x74e
V  [libjvm.so+0x17ae72a]  VMThread::run()+0xca
V  [libjvm.so+0x16c6ab6]  Thread::call_run()+0xf6
V  [libjvm.so+0x13e1bfe]  thread_native_entry(Thread*)+0x10e

Comments
Verified by regular testing.
05-08-2019

Fix Request (11u) Resolves JVM crash when dealing with dead classes/objects during class inspection. Needs JDK-8220682 and JDK-8212992 to be applied first. This patch applies to 11u cleanly, passes tier1. Risk is low: skips dead classes and avoids resurrecting them too.
24-07-2019

Also depends on JDK-8212992 that introduces Klass::java_mirror_no_keepalive().
24-07-2019

Some paths in heapInspection.cpp that are fixed by this patch are introduced by JDK-8220682.
24-07-2019

URL: http://hg.openjdk.java.net/jdk/jdk13/rev/29e522153769 User: eosterlund Date: 2019-07-09 15:45:40 +0000
09-07-2019

I thought I understood the race. But afterlooking more closely, I no longer think I understood it. But I will take the bug anyway. The way that the safepoint cleanup code and CMS thread compete for setting and clearing the boolean for wether purging must be run without any synchronization looks really scary (the CMS thread sets its value without token synchronization, i.e. while running straight through sfepoints). But I have yet to think of a scenario that would manifest in this way.
03-06-2019

This bug has only been seen with CMS. [~eosterlund] can explain why it's a bug in CMS.
28-05-2019