The following test failed in the JDK14 CI:

applications/kitchensink/Kitchensink.java

Here's a snippet from the hs_err_pid file:

# Internal Error (open/src/hotspot/share/classfile/javaClasses.cpp:3879), pid=5763, tid=5781
# assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop
#
# JRE version: Java(TM) SE Runtime Environment (14.0+7) (fastdebug build 14-ea+7-194)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+7-194, mixed mode, tiered, z gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xe09ff5] java_lang_ClassLoader::loader_data_raw(oop)+0xe5

Here's the crashing thread:

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

Current thread (0x00007f015c2d4e30): VMThread "VM Thread" [stack: 0x00007f0144068000,0x00007f0144168000] [id=5781]

Stack: [0x00007f0144068000,0x00007f0144168000], sp=0x00007f0144166610, free space=1017k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xe09ff5] java_lang_ClassLoader::loader_data_raw(oop)+0xe5
V [libjvm.so+0x1833b19] void InstanceClassLoaderKlass::oop_oop_iterate<oop, ZHeapIteratorOopClosure<true> >(oop, ZHeapIteratorOopClosure<true>*)+0x199
V [libjvm.so+0x1833baa] void OopOopIterateDispatch<ZHeapIteratorOopClosure<true> >::Table::oop_oop_iterate<InstanceClassLoaderKlass, oop>(ZHeapIteratorOopClosure<true>*, oop, Klass*)+0x3a
V [libjvm.so+0x18315da] void ZHeapIterator::push_fields<true>(oop)+0x9a
V [libjvm.so+0x1832057] void ZHeapIterator::objects_do<true>(ObjectClosure*)+0x177
V [libjvm.so+0x182bf0f] ZHeap::object_iterate(ObjectClosure*, bool)+0x6f
V [libjvm.so+0x112d2c9] VM_HeapIterateOperation::doit()+0x49
V [libjvm.so+0x178d853] VM_Operation::evaluate()+0x143
V [libjvm.so+0x17bcfaf] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.66]+0x17f
V [libjvm.so+0x17bda5e] VMThread::loop()+0x74e
V [libjvm.so+0x17bddda] VMThread::run()+0xca
V [libjvm.so+0x16d5a56] Thread::call_run()+0xf6
V [libjvm.so+0x13f272e] thread_native_entry(Thread*)+0x10e

[~eosterlund] - This bug might interest you. It may be due
to the same failure mode as JDK-8227407, but the failing
test and failure mode are different so I filed a new bug.