<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's the exact reason of the crash? Is it due to dereferencing invalid<br>metadata pointer or simply encountering a nullptr?<br clear="all"></blockquote><div><br></div><div>It's nullptr. The klass pointer of the method is null.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">*TrainingData::cleanup() was intended to clear stale metadata pointers,<br>but keep the training data around linked in symbolic form (holder == null).<br></blockquote><div><br></div><div>Okay, so if we do want to keep the training data but just prune the stale pointers,</div><div>then just setting the _holder to null is not enough, because the method belonging</div><div>to an excluded class can be reached through MethodTrainingData::_final_profile->method() or</div><div>MethodTrainingData::_final_counters->method(). <br></div><div>So probably MethodTrainingData::cleanup() should be clearing the _method field in </div><div>MethodCounters and MethodData as well, and link them back in MethodTrainingData::refresh_from(), </div><div>just like it is done for MethodTrainingData.</div><div>Does that make sense?</div><div><br></div><div>Thanks,</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Ashutosh Mehra</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 28, 2024 at 5:33 PM Vladimir Ivanov <<a href="mailto:vladimir.x.ivanov@oracle.com">vladimir.x.ivanov@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's the exact reason of the crash? Is it due to dereferencing invalid <br>
metadata pointer or simply encountering a nullptr?<br>
<br>
*TrainingData::cleanup() was intended to clear stale metadata pointers, <br>
but keep the training data around linked in symbolic form (holder == null).<br>
<br>
Best regards,<br>
Vladimir Ivanov<br>
<br>
On 6/27/24 20:14, Ashutosh Mehra wrote:<br>
> I encountered a crash when dumping the cds map with 1-step workflow.<br>
> The crash happens in the forked JVM during the assembly phase of the <br>
> training run.<br>
> To recreate the crash, execute the training run with <br>
> -Xlog:cds+map=trace:file=cds.map:none:filesize=0 option.<br>
> <br>
> #<br>
> # A fatal error has been detected by the Java Runtime Environment:<br>
> #<br>
> #  SIGSEGV (0xb) at pc=0x00007f4e8a209cb6, pid=152509, tid=152510<br>
> #<br>
> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build <br>
> 23-internal-adhoc.asmehra.leyden)<br>
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug <br>
> 23-internal-adhoc.asmehra.leyden, mixed mode, sharing, tiered, <br>
> compressed oops, compressed class ptrs, g1 gc, linux-amd64)<br>
> # Problematic frame:<br>
> # V  [libjvm.so+0x409cb6]  Klass::is_instance_klass() const+0x10<br>
> #<br>
> # Core dump will be written. Default location: <br>
> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/core.152509<br>
> #<br>
> # An error report file with more information is saved as:<br>
> # <br>
> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/hs_err_pid152509.log<br>
> #<br>
> # If you would like to submit a bug report, please visit:<br>
> # <a href="https://bugreport.java.com/bugreport/crash.jsp" rel="noreferrer" target="_blank">https://bugreport.java.com/bugreport/crash.jsp</a> <br>
> <<a href="https://bugreport.java.com/bugreport/crash.jsp" rel="noreferrer" target="_blank">https://bugreport.java.com/bugreport/crash.jsp</a>><br>
> #<br>
> [75.250s][error  ][cds] Child process finished; status = 134<br>
> <br>
> Backtrace for the crashing thread:<br>
> <br>
> #11 0x00007f4e8a209cb6 in Klass::is_instance_klass (this=0x0) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.hpp:683<br>
> #12 0x00007f4e8afa8894 in Klass::external_name (this=0x0) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.cpp:905<br>
> #13 0x00007f4e8b126447 in Method::print_external_name <br>
> (os=0x7f4e89dfd130, klass=0x0, method_name=0x8011e8588, <br>
> signature=0x8011ab858) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:228<br>
> #14 0x00007f4e8b1263b6 in Method::external_name (klass=0x0, <br>
> method_name=0x8011e8588, signature=0x8011ab858) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:222<br>
> #15 0x00007f4e8b1262e1 in Method::external_name (this=0x800fd1920) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:213<br>
> #16 0x00007f4e8a492b0d in ArchiveBuilder::CDSMapLogger::log_method <br>
> (m=0x800fd1920, runtime_dest=0x801039cd8 "", type_name=0x7f4e8b7d40fc <br>
> "Method", bytes=128, current=0x7f4e8401d900)<br>
>      at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1194<br>
> #17 0x00007f4e8a492d66 in <br>
> ArchiveBuilder::CDSMapLogger::log_metaspace_objects <br>
> (region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1228<br>
> #18 0x00007f4e8a492a2b in <br>
> ArchiveBuilder::CDSMapLogger::log_metaspace_region (name=0x7f4e8b7d8af0 <br>
> "rw region", region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1182<br>
> #19 0x00007f4e8a4940f4 in ArchiveBuilder::CDSMapLogger::log <br>
> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, <br>
> heap_info=0x7f4e89dfd4f0, bitmap=0x7f4e857bf850 <br>
> "\t\222\004I\222$\t\210\210\210\001\b\200", bitmap_size_in_bytes=655824)<br>
>      at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1502<br>
> #20 0x00007f4e8a48f2a5 in ArchiveBuilder::write_archive <br>
> (this=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, heap_info=0x7f4e89dfd4f0) <br>
> at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1560<br>
> #21 0x00007f4e8b11d249 in MetaspaceShared::write_static_archive <br>
> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, <br>
> heap_info=0x7f4e89dfd4f0) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:988<br>
> #22 0x00007f4e8b11d1ac in MetaspaceShared::preload_and_dump_impl <br>
> (builder=..., __the_thread__=0x7f4e8401d900) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:976<br>
> #23 0x00007f4e8b11c5fd in MetaspaceShared::preload_and_dump () at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:767<br>
> #24 0x00007f4e8b53bca2 in Threads::create_vm (args=0x7f4e89dfedd0, <br>
> canTryAgain=0x7f4e89dfecd3) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/threads.cpp:900<br>
> #25 0x00007f4e8ada2821 in JNI_CreateJavaVM_inner (vm=0x7f4e89dfee20, <br>
> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3581<br>
> #26 0x00007f4e8ada2c81 in JNI_CreateJavaVM (vm=0x7f4e89dfee20, <br>
> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3672<br>
> #27 0x00007f4e8ce0f84f in InitializeJVM (pvm=0x7f4e89dfee20, <br>
> penv=0x7f4e89dfee28, ifn=0x7f4e89dfee70) at <br>
> /home/asmehra/data/ashu-mehra/leyden/src/java.base/share/native/libjli/java.c:1550<br>
> <br>
> Checking up the CDS map generated for the cds preimage shows some <br>
> methods for which their InstanceKlass is null.<br>
> This results in the crash seen above when such methods are printed as <br>
> part of the CDS map file during the assembly phase.<br>
> <br>
> These methods are of the form:<br>
> <br>
> java.lang.Object <br>
> java.lang.invoke.LambdaForm$MH/0x800000090.invoke(java.lang.Object, <br>
> java.lang.Object)<br>
> <br>
> Interestingly -Xlog:cds=info shows such classes are skipped when <br>
> generating the preimage as they are hidden classes:<br>
> <br>
> Skipping java/lang/invoke/LambdaForm$MH+0x800000090: Hidden class<br>
> <br>
> In the CDS map file for the preimage I also noticed that such methods <br>
> are only referenced through MethodTrainingData -> _final_profile -> _method.<br>
> So it looks like although we excluded such classes from the CDS archive, <br>
> we don't exclude their training data.<br>
> There is code for cleaning up the training data [0] , but it doesn't <br>
> remove the training data for classes that have been excluded, unless I <br>
> misunderstood the code.<br>
> Not sure if it is intentional or a bug.<br>
> If we do need to keep the training data for such methods, then we would <br>
> need to handle the case of null InstanceKlass in the CDSMapLogger to <br>
> avoid crashing.<br>
> <br>
> [0] <br>
> <a href="https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573" rel="noreferrer" target="_blank">https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573</a> <<a href="https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573" rel="noreferrer" target="_blank">https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573</a>><br>
> <br>
> Thanks,<br>
> - Ashutosh Mehra<br>
<br>
</blockquote></div>