Crash when dumping cds map file

Fri Jun 28 21:33:08 UTC 2024

What's the exact reason of the crash? Is it due to dereferencing invalid 
metadata pointer or simply encountering a nullptr?

*TrainingData::cleanup() was intended to clear stale metadata pointers, 
but keep the training data around linked in symbolic form (holder == null).

Best regards,
Vladimir Ivanov

On 6/27/24 20:14, Ashutosh Mehra wrote:
> I encountered a crash when dumping the cds map with 1-step workflow.
> The crash happens in the forked JVM during the assembly phase of the 
> training run.
> To recreate the crash, execute the training run with 
> -Xlog:cds+map=trace:file=cds.map:none:filesize=0 option.
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f4e8a209cb6, pid=152509, tid=152510
> #
> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 
> 23-internal-adhoc.asmehra.leyden)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 
> 23-internal-adhoc.asmehra.leyden, mixed mode, sharing, tiered, 
> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x409cb6]  Klass::is_instance_klass() const+0x10
> #
> # Core dump will be written. Default location: 
> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/core.152509
> #
> # An error report file with more information is saved as:
> # 
> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/hs_err_pid152509.log
> #
> # If you would like to submit a bug report, please visit:
> # https://bugreport.java.com/bugreport/crash.jsp 
> <https://bugreport.java.com/bugreport/crash.jsp>
> #
> [75.250s][error  ][cds] Child process finished; status = 134
> 
> Backtrace for the crashing thread:
> 
> #11 0x00007f4e8a209cb6 in Klass::is_instance_klass (this=0x0) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.hpp:683
> #12 0x00007f4e8afa8894 in Klass::external_name (this=0x0) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.cpp:905
> #13 0x00007f4e8b126447 in Method::print_external_name 
> (os=0x7f4e89dfd130, klass=0x0, method_name=0x8011e8588, 
> signature=0x8011ab858) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:228
> #14 0x00007f4e8b1263b6 in Method::external_name (klass=0x0, 
> method_name=0x8011e8588, signature=0x8011ab858) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:222
> #15 0x00007f4e8b1262e1 in Method::external_name (this=0x800fd1920) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:213
> #16 0x00007f4e8a492b0d in ArchiveBuilder::CDSMapLogger::log_method 
> (m=0x800fd1920, runtime_dest=0x801039cd8 "", type_name=0x7f4e8b7d40fc 
> "Method", bytes=128, current=0x7f4e8401d900)
>      at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1194
> #17 0x00007f4e8a492d66 in 
> ArchiveBuilder::CDSMapLogger::log_metaspace_objects 
> (region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1228
> #18 0x00007f4e8a492a2b in 
> ArchiveBuilder::CDSMapLogger::log_metaspace_region (name=0x7f4e8b7d8af0 
> "rw region", region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1182
> #19 0x00007f4e8a4940f4 in ArchiveBuilder::CDSMapLogger::log 
> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, 
> heap_info=0x7f4e89dfd4f0, bitmap=0x7f4e857bf850 
> "\t\222\004I\222$\t\210\210\210\001\b\200", bitmap_size_in_bytes=655824)
>      at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1502
> #20 0x00007f4e8a48f2a5 in ArchiveBuilder::write_archive 
> (this=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, heap_info=0x7f4e89dfd4f0) 
> at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1560
> #21 0x00007f4e8b11d249 in MetaspaceShared::write_static_archive 
> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, 
> heap_info=0x7f4e89dfd4f0) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:988
> #22 0x00007f4e8b11d1ac in MetaspaceShared::preload_and_dump_impl 
> (builder=..., __the_thread__=0x7f4e8401d900) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:976
> #23 0x00007f4e8b11c5fd in MetaspaceShared::preload_and_dump () at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:767
> #24 0x00007f4e8b53bca2 in Threads::create_vm (args=0x7f4e89dfedd0, 
> canTryAgain=0x7f4e89dfecd3) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/threads.cpp:900
> #25 0x00007f4e8ada2821 in JNI_CreateJavaVM_inner (vm=0x7f4e89dfee20, 
> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3581
> #26 0x00007f4e8ada2c81 in JNI_CreateJavaVM (vm=0x7f4e89dfee20, 
> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3672
> #27 0x00007f4e8ce0f84f in InitializeJVM (pvm=0x7f4e89dfee20, 
> penv=0x7f4e89dfee28, ifn=0x7f4e89dfee70) at 
> /home/asmehra/data/ashu-mehra/leyden/src/java.base/share/native/libjli/java.c:1550
> 
> Checking up the CDS map generated for the cds preimage shows some 
> methods for which their InstanceKlass is null.
> This results in the crash seen above when such methods are printed as 
> part of the CDS map file during the assembly phase.
> 
> These methods are of the form:
> 
> java.lang.Object 
> java.lang.invoke.LambdaForm$MH/0x800000090.invoke(java.lang.Object, 
> java.lang.Object)
> 
> Interestingly -Xlog:cds=info shows such classes are skipped when 
> generating the preimage as they are hidden classes:
> 
> Skipping java/lang/invoke/LambdaForm$MH+0x800000090: Hidden class
> 
> In the CDS map file for the preimage I also noticed that such methods 
> are only referenced through MethodTrainingData -> _final_profile -> _method.
> So it looks like although we excluded such classes from the CDS archive, 
> we don't exclude their training data.
> There is code for cleaning up the training data [0] , but it doesn't 
> remove the training data for classes that have been excluded, unless I 
> misunderstood the code.
> Not sure if it is intentional or a bug.
> If we do need to keep the training data for such methods, then we would 
> need to handle the case of null InstanceKlass in the CDSMapLogger to 
> avoid crashing.
> 
> [0] 
> https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573 <https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573>
> 
> Thanks,
> - Ashutosh Mehra