JDK-8202669 : Intermittent crash in ClassLoadingService::compute_class_size()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-05-04
  • Updated: 2019-06-20
  • Resolved: 2018-05-22
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
11 b15Fixed
Related Reports
Duplicate :  
JDK-8202665 - G1ConcurrentMark fails when computing class size
Relates :  
JDK-8202447 - Fix unloading_occurred to mean unloading_occurred
Relates :  
JDK-8200466 - Revisit the setting of _transitive_interfaces in InstanceKlass
Relates :  
JDK-8202578 - Revisit location for class unload events
Description
After pulling latest changes from jdk/jdk I start observing crashes when run with -Xcomp.

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffded239abe, pid=8904, tid=10236
#
# JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-2018-05-03-1918347.vladimir.kozlov.jdkjdk)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-2018-05-03-1918347.vladimir.kozlov.jdkjdk, compiled mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x469abe]  ClassLoadingService::compute_class_size+0x6e
#

V  [jvm.dll+0x469abe]  ClassLoadingService::compute_class_size+0x6e  (classloadingservice.cpp:175)
V  [jvm.dll+0x469d7b]  ClassLoadingService::notify_class_unloaded+0x3b  (classloadingservice.cpp:130)
V  [jvm.dll+0x463b24]  ClassLoaderData::classes_do+0x94  (classloaderdata.cpp:339)
V  [jvm.dll+0x46746a]  ClassLoaderData::unload+0x3a  (classloaderdata.cpp:578)
V  [jvm.dll+0x46483f]  ClassLoaderDataGraph::do_unloading+0xef  (classloaderdata.cpp:1320)
V  [jvm.dll+0xbebf55]  SystemDictionary::do_unloading+0x215  (systemdictionary.cpp:1851)
V  [jvm.dll+0x606774]  G1ConcurrentMark::weak_refs_work+0x624  (g1concurrentmark.cpp:1705)
V  [jvm.dll+0x6047e0]  G1ConcurrentMark::remark+0x2d0  (g1concurrentmark.cpp:1164)
V  [jvm.dll+0xc816ef]  VM_CGC_Operation::doit+0x12f  (vm_operations_g1.cpp:211)
V  [jvm.dll+0xc80ebb]  VM_Operation::evaluate+0xcb  (vm_operations.cpp:69)
V  [jvm.dll+0xc7e4c6]  VMThread::evaluate_operation+0xd6  (vmthread.cpp:355)
V  [jvm.dll+0xc7efb4]  VMThread::loop+0x524  (vmthread.cpp:498)
V  [jvm.dll+0xc7f88d]  VMThread::run+0xfd  (vmthread.cpp:271)

Stefan K. pointed possible candidates for regression: JDK-8200466 and JDK-8202447.
From the list of changes I pulled when crash started I see 8202447. This will be my first candidate.
Comments
Test added is executed in tiered testing and no longer crashes.
06-06-2018
If I backout the fix for JDK-8202447 the crash still occurs.
18-05-2018
A simple NULL check should fix the problem. bash-4.2$ hg diff src/hotspot/share/services/classLoadingService.cpp diff --git a/src/hotspot/share/services/classLoadingService.cpp b/src/hotspot/share/services/classLoadingService.cpp --- a/src/hotspot/share/services/classLoadingService.cpp +++ b/src/hotspot/share/services/classLoadingService.cpp @@ -172,7 +172,9 @@ // FIXME: Need to count the contents of methods class_size += k->constants()->size(); class_size += k->local_interfaces()->size(); - class_size += k->transitive_interfaces()->size(); + if (k->transitive_interfaces() != NULL) { + class_size += k->transitive_interfaces()->size(); + } // We do not have to count implementors, since we only store one! // FIXME: How should these be accounted for, now when they have moved. //class_size += k->fields()->size(); I ran the affected tests 30 times with the above change with -Xcomp on Oracle platforms and didn't see any failures.
11-05-2018
It looks like the InstanceKlass being unloaded is in some kind of intermediate, maybe corrupt, state (was problematic InstanceKlasses included in updates to unloading? Or maybe they were always there but now something else assumes every unloaded class to be well-formed?) ... +0x122 _misc_flags : 0x18 +0x124 _minor_version : 0 +0x126 _major_version : 0x30 +0x128 _init_thread : (null) +0x130 _oop_map_cache : (null) +0x138 _jni_ids : (null) +0x140 _methods_jmethod_ids : (null) +0x148 _dep_context : 0n0 +0x150 _osr_nmethods_head : (null) +0x158 _breakpoints : (null) +0x160 _previous_versions : (null) +0x168 _cached_class_file : (null) +0x170 _idnum_allocated_count : 2 +0x172 _init_state : 0 '' <<----------------------- ?? +0x098 _class_loader_data : 0x00000015`a9a0bd30 ClassLoaderData 0x00000015`a9a0bd30: +0x028 _unloading : 1 ... +0x088 _class_loader_klass : 0x00000007`c00d7840 Klass 0x00000007`c00d7840: [+0x018] _name : 0x15a6c955a0 0x15a6c955a0 + 0x6 == "Test6194361" <<--- Klass name for the ClassLoader associated with this ClassLoaderData
07-05-2018
I checked one of the .mdmp files very quickly: # RetAddr : Args to Child : Call Site 00 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : jvm!Array<Klass *>::size [t:\workspace\open\src\hotspot\share\oops\array.hpp @ 136] 01 00007ff8`2412a74b : 00000007`c00d7040 00000007`c00d7040 00000000`00000000 00000000`00000000 : jvm!ClassLoadingService::compute_class_size+0x6e [t:\workspace\open\src\hotspot\share\services\classloadingservice.cpp @ 175] 02 00007ff8`24124644 : 00000007`c00d7040 00000007`c00d7040 00000007`c00d7040 00000015`a485eb00 : jvm!ClassLoadingService::notify_class_unloaded+0x3b [t:\workspace\open\src\hotspot\share\services\classloadingservice.cpp @ 130] 03 00007ff8`24127f8a : 00000015`a9a0bd30 00007ff8`2439b120 00000015`a9a09790 00000015`a9a0bd30 : jvm!ClassLoaderData::classes_do+0x94 [t:\workspace\open\src\hotspot\share\classfile\classloaderdata.cpp @ 339] 04 00007ff8`2412535f : 00000015`a9a0bd30 00007ff8`00000000 00000182`62494858 00007ff8`2416c53b : jvm!ClassLoaderData::unload+0x3a [t:\workspace\open\src\hotspot\share\classfile\classloaderdata.cpp @ 578] 05 00007ff8`248ad4a5 : 00000015`823ed800 00000015`823ed810 00000015`a485eb49 00000000`00000001 : jvm!ClassLoaderDataGraph::do_unloading+0xef [t:\workspace\open\src\hotspot\share\classfile\classloaderdata.cpp @ 1320] 06 00007ff8`242c6be4 : 00000015`a485ebf0 00000015`823ed810 00000015`823ed800 00000000`0000000b : jvm!SystemDictionary::do_unloading+0x215 [t:\workspace\open\src\hotspot\share\classfile\systemdictionary.cpp @ 1851] 07 00007ff8`242c4c50 : 00000015`823ed190 00000015`a3c68000 00000015`a3c68000 00007ff8`00000000 : jvm!G1ConcurrentMark::weak_refs_work+0x624 [t:\workspace\open\src\hotspot\share\gc\g1\g1concurrentmark.cpp @ 1705] 08 00007ff8`24942faf : 00000015`823ed190 00007ff8`24ab6670 00000015`a3c68000 00000000`00000000 : jvm!G1ConcurrentMark::remark+0x2d0 [t:\workspace\open\src\hotspot\share\gc\g1\g1concurrentmark.cpp @ 1164] 09 00007ff8`2494272b : 00000015`a0fef6b0 00000015`a0fef6b0 00007ff8`24a2e5d8 00007ff8`0000000c : jvm!VM_CGC_Operation::doit+0x12f [t:\workspace\open\src\hotspot\share\gc\g1\vm_operations_g1.cpp @ 211] 0a 00007ff8`2493fd26 : 00000015`a0fef6b0 00000015`a3c5d650 00000000`00000000 00000000`00000000 : jvm!VM_Operation::evaluate+0xcb [t:\workspace\open\src\hotspot\share\runtime\vm_operations.cpp @ 69] 0b 00007ff8`24940814 : 00000015`a3c68000 00000015`a0fef6b0 00000015`a3c5d650 00000000`000003e8 : jvm!VMThread::evaluate_operation+0xd6 [t:\workspace\open\src\hotspot\share\runtime\vmthread.cpp @ 355] 0c 00007ff8`249410ed : 00000015`a3c68000 00000015`a3c68000 00000015`a485fb50 00000000`000075a3 : jvm!VMThread::loop+0x524 [t:\workspace\open\src\hotspot\share\runtime\vmthread.cpp @ 498] 0d 00007ff8`24772bfc : 00000015`a3c68000 00000015`a3c68000 00000000`00000000 00000000`00000000 : jvm!VMThread::run+0xfd [t:\workspace\open\src\hotspot\share\runtime\vmthread.cpp @ 271] 0e 00007ff8`26ae4f7f : 00000015`a3c68000 00000000`00000000 00000015`a3c7eb70 00000015`a3c7fc20 : jvm!thread_native_entry+0x11c [t:\workspace\open\src\hotspot\os\windows\os_windows.cpp @ 457] 0f 00007ff8`26ae5126 : 00007ff8`26b9cb80 00000000`00000000 00000000`00000000 00000000`00000000 : msvcr120!_callthreadstartex+0x17 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 10 00007ff8`31b713d2 : 00007ff8`26ae5024 00000015`a3c7eb70 00000000`00000000 00000000`00000000 : msvcr120!_threadstartex+0x102 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 11 00007ff8`323b54f4 : 00007ff8`31b713b0 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x22 12 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34 size_t ClassLoadingService::compute_class_size(InstanceKlass* k) { // lifted from ClassStatistics.do_class(Klass* k) size_t class_size = 0; class_size += k->size(); if (k->is_instance_klass()) { class_size += k->methods()->size(); // FIXME: Need to count the contents of methods class_size += k->constants()->size(); class_size += k->local_interfaces()->size(); class_size += k->transitive_interfaces()->size(); <<-- here InstanceKlass* k: +0x1a0 _transitive_interfaces : (null) <<-- NULL +0x018 _name : 0x00000015`a3a25380 Symbol 0x00000015`a3a25380 + 0x6 == "java/lang/Object" ... +0x030 _primary_supers : [8] 0x00000007`c00d7040 Klass [0] : 0x7c00d7040 [Type: Klass *] [1] : 0x0 [Type: Klass *] [2] : 0x0 [Type: Klass *] [3] : 0x0 [Type: Klass *] [4] : 0x0 [Type: Klass *] [5] : 0x0 [Type: Klass *] [6] : 0x0 [Type: Klass *] [7] : 0x0 [Type: Klass *] address for k* == 0x00000007`c00d7040 // <--- note address of k* and primary_supers... [+0x078] _super : 0x0 [Type: Klass *] Is this java/lang/Object? Are we unloading java/lang/Object?
04-05-2018
I attached 2 hs_err files from windows and linux.
04-05-2018