JDK-8267345 : VM crashes during dumping classlist with -Xshare:dump option
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-05-18
  • Updated: 2021-05-27
  • Resolved: 2021-05-20
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 16
16.0.2 b06Fixed
Related Reports
Duplicate :  
JDK-8267346 - java -Xshare:dump -XX:DumpLoadedClassList=... crashes
Relates :  
JDK-8247536 - Support for pre-generated java.lang.invoke classes in CDS static archive
Description
VM crashes under special situation when both -Xshare:dump and -XX:DumpLoadedClassList options are specified.

Stack: [0x00007fc45d8ff000,0x00007fc45da00000],  sp=0x00007fc45d9fd168,  free space=1016k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x13fb6c]  __strncmp_sse42+0x2c
V  [libjvm.so+0xa95cc9]  InstanceKlass::print_class_load_logging(ClassLoaderData*, ModuleEntry const*, ClassFileStream const*) const+0x41
V  [libjvm.so+0x742612]  ClassFileParser::fill_instance_klass(InstanceKlass*, bool, ClassInstanceInfo const&, Thread*)+0xf74
V  [libjvm.so+0x7414e5]  ClassFileParser::create_instance_klass(bool, ClassInstanceInfo const&, Thread*)+0xdd
V  [libjvm.so+0xd968ce]  KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, Thread*)+0x32e
V  [libjvm.so+0xd9de55]  LambdaFormInvokers::reload_class(char*, ClassFileStream&, Thread*)+0x11f
V  [libjvm.so+0xd9dc30]  LambdaFormInvokers::regenerate_holder_classes(Thread*)+0x5a2
V  [libjvm.so+0xf0089c]  MetaspaceShared::preload_and_dump(Thread*)+0x37a
V  [libjvm.so+0x11baee3]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x9af
V  [libjvm.so+0xb9a420]  JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0xda
V  [libjvm.so+0xb9a725]  JNI_CreateJavaVM+0x32
C  [libjli.so+0x7664]  InitializeJVM+0x13d
C  [libjli.so+0x4252]  JavaMain+0xdc
C  [libjli.so+0xaf77]  ThreadJavaMain+0x27
Comments
Changeset: 5311c4d4 Author: Yumin Qi <minqi@openjdk.org> Date: 2021-05-20 15:28:08 +0000 URL: https://git.openjdk.java.net/jdk16u/commit/5311c4d454bc30a357d0a066f8cb919d89792836
20-05-2021
The failure is caused from lambda function generating, the use case is not common case. When -Xshare:dump, we often appoint a class list using -XX:SharedClassListFile not -XX:DumpLoadedClassList (The pre-step to collecting loaded classes). -Xshare:dump without -XX:SharedClassListFile in fact will regenerate the default archive. At regenerating the lambda invoker holder class, the source associates with stream is NULL --- it is generated on fly. To fix this, we can either backport 17 implementation or check the source, if it is NULL --- skip it. Since the loader is boot loader or platform loader, if source is NULL, it has to be some reason for it, like this case, it does not have a source with it.
19-05-2021
Simple reproducer: $ java -version java version "16" 2021-03-16 Java(TM) SE Runtime Environment (build 16+36-2231) Java HotSpot(TM) 64-Bit Server VM (build 16+36-2231, mixed mode, sharing) $ java -Xshare:dump -XX:DumpLoadedClassList=foo.txt # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f4a2417bd80, pid=9476, tid=9477 # # JRE version: Java(TM) SE Runtime Environment (16.0+36) (build 16+36-2231) # Java VM: Java HotSpot(TM) 64-Bit Server VM (16+36-2231, interpreted mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x7d7d80] InstanceKlass::print_class_load_logging(ClassLoaderData*, ModuleEntry const*, ClassFileStream const*) const+0x850 # ... Stack: [0x00007f4a256db000,0x00007f4a257dc000], sp=0x00007f4a257d9370, 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+0x7d7d80] InstanceKlass::print_class_load_logging(ClassLoaderData*, ModuleEntry const*, ClassFileStream const*) const+0x850 V [libjvm.so+0x554c1e] ClassFileParser::fill_instance_klass(InstanceKlass*, bool, ClassInstanceInfo const&, Thread*)+0xb9e V [libjvm.so+0x554fd2] ClassFileParser::create_instance_klass(bool, ClassInstanceInfo const&, Thread*)+0x72 V [libjvm.so+0xa2080c] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, Thread*)+0x1cc V [libjvm.so+0xa2441e] LambdaFormInvokers::reload_class(char*, ClassFileStream&, Thread*)+0x7e V [libjvm.so+0xa248d2] LambdaFormInvokers::regenerate_holder_classes(Thread*)+0x3d2 V [libjvm.so+0xb5adaf] MetaspaceShared::preload_and_dump(Thread*)+0x18f V [libjvm.so+0xd846fb] Threads::create_vm(JavaVMInitArgs*, bool*)+0xaeb V [libjvm.so+0x890191] JNI_CreateJavaVM+0x51 C [libjli.so+0x39bf] JavaMain+0x8f C [libjli.so+0x7ec9] ThreadJavaMain+0x9
19-05-2021
This bug was introduced by JDK-8247536 in JDK 16.
18-05-2021
The problem is in the InstanceKlass::log_to_classlist() https://github.com/openjdk/jdk16u/blob/e84e18580d764f612b9afaee7a470cde856a6bcc/src/hotspot/share/oops/instanceKlass.cpp#L4243 Sometimes the stream->source() could be NULL. klass like java/lang/invoke/BoundMethodHandle$Species_D would have a NULL source. This bug is not applicable to JDK 17.
18-05-2021