JDK-8164132 : vm/classfile/classLoaderData.hpp:288 assert(!(is_the_null_class_loader_data() && _unloading)) failed: The null class loader can never be unloaded
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-08-16
  • Updated: 2016-08-17
  • Resolved: 2016-08-17
Related Reports
Duplicate :  
Description
PIT testing, happened once on linux-x64

#  Internal Error (/scratch/opt/jprt/T/P1/205858.amurillo/s/hotspot/src/share/vm/classfile/classLoaderData.hpp:288), pid=301, tid=341
#  assert(!(is_the_null_class_loader_data() && _unloading)) failed: The null class loader can never be unloaded
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-08-12-205858.amurillo.jdk9-hs-2016-08-12-snapshot)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-08-12-205858.amurillo.jdk9-hs-2016-08-12-snapshot, mixed mode, tiered, compressed oops, concurrent mark sweep gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" (or dumping to /scratch/home/aurora/sandbox/results/ResultDir/lp30yp10rp30mr70st0/core.301)
#
# 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: -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -XX:+UseConcMarkSweepGC -XX:-UseGCOverheadLimit vm.gc.concurrent.Concurrent -lp 30 -yp 10 -rp 30 -mr 70 -st 0 -ms high -gp random(arrays) -gp1 nonbranchyTree(low)

Host: scaaa603.us.oracle.com, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 251G, Oracle Linux Server release 7.0
Time: Sat Aug 13 09:10:40 2016 PDT elapsed time: 2 seconds (0d 0h 0m 2s)

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

Current thread (0x00007f3e102a9000):  VMThread "VM Thread" [stack: 0x00007f3d67304000,0x00007f3d67405000] [id=341]

Stack: [0x00007f3d67304000,0x00007f3d67405000],  sp=0x00007f3d67403240,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x16a2392]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162
V  [libjvm.so+0x16a310f]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V  [libjvm.so+0xa6856d]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.so+0xb4d758]  Dictionary::do_unloading()+0x228
V  [libjvm.so+0x15ab33a]  SystemDictionary::do_unloading(BoolObjectClosure*, bool)+0x2a
V  [libjvm.so+0xa37d57]  CMSCollector::refProcessingWork()+0x4e7
V  [libjvm.so+0xa39780]  CMSCollector::checkpointRootsFinalWork()+0x1c0
V  [libjvm.so+0xa39d3b]  CMSCollector::checkpointRootsFinal()+0x14b
V  [libjvm.so+0xa39f5f]  CMSCollector::do_CMS_operation(CMSCollector::CMS_op_type, GCCause::Cause)+0x14f
V  [libjvm.so+0x169ea1b]  VM_CMS_Final_Remark::doit()+0x12b
V  [libjvm.so+0x16e3e99]  VM_Operation::evaluate()+0xa9
V  [libjvm.so+0x16dec3f]  VMThread::evaluate_operation(VM_Operation*)+0x15f
V  [libjvm.so+0x16df609]  VMThread::loop()+0x269
V  [libjvm.so+0x16dfcb0]  VMThread::run()+0xc0
V  [libjvm.so+0x13487a2]  thread_native_entry(Thread*)+0x112

VM_Operation (0x00007f3d850e9df0): CMS_Final_Remark, mode: safepoint, requested by thread 0x00007f3e10196000
Comments
Probably a duplicate of JDK-8162553, but that bug has already been fixed ...
17-08-2016