[jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive
Coleen Phillimore
coleenp at openjdk.java.net
Wed Dec 16 01:34:58 UTC 2020
On Wed, 16 Dec 2020 01:15:07 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:
>> src/hotspot/share/classfile/classListParser.cpp line 467:
>>
>>> 465: Handle class_loader(THREAD, SystemDictionary::java_system_loader());
>>> 466: Handle protection_domain;
>>> 467: Klass* klass = SystemDictionary::resolve_or_fail(class_name_symbol, class_loader, protection_domain, true, THREAD); // FIXME should really be just a lookup
>>
>> If an exception is unexpected, this should be CHECK not THREAD.
>
> I'll try CHECK and do more testing before posting an updated webrev.
>
> Thanks for your review.
For this change, don't change it to CHECK in case something new will fail, and any new exceptions will caught by checking k != NULL. It just looks strange but can be cleaned up later.
>> src/hotspot/share/classfile/classListParser.cpp line 474:
>>
>>> 472: return;
>>> 473: }
>>> 474: MetaspaceShared::try_link_class(ik, THREAD);
>>
>> Doesn't the check for failing verification belong after try_link_class(), which runs the verifier?
>
> Linking attempt was done for the class and was marked as failed verification prior to getting into `ClassListParser::resolve_indy`.
>
> Consider the following class list (from the test case):
> BadInvokeDynamic
> @lambda-proxy BadInvokeDynamic run ()Ljava/lang/Runnable; ()V REF_invokeStatic BadInvokeDynamic lambda$doTest$0 ()V ()V
>
> The BadInvokeDynamic was linked via the following code path:
> MetaspaceShared::try_link_class() at metaspaceShared.cpp:1,161 0x7ffff63b1c10
> MetaspaceShared::preload_classes() at metaspaceShared.cpp:1,125 0x7ffff63b1a42
> MetaspaceShared::preload_and_dump() at metaspaceShared.cpp:1,047 0x7ffff63b1557
> Threads::create_vm() at thread.cpp:3,809 0x7ffff666b3f9
> JNI_CreateJavaVM_inner() at jni.cpp:3,769 0x7ffff604b1be
> JNI_CreateJavaVM() at jni.cpp:3,852 0x7ffff604b4c3
> InitializeJVM() at java.c:1,536 0x7ffff7fcd664
> JavaMain() at java.c:416 0x7ffff7fca252
> ThreadJavaMain() at java_md.c:651 0x7ffff7fd0f77
> start_thread() at 0x7ffff79b0ea5
>
> It was marked as failed verification in `MetaspaceShared::try_link_class` in the following:
> ik->link_class(THREAD);
> if (HAS_PENDING_EXCEPTION) {
> ResourceMark rm(THREAD);
> log_warning(cds)("Preload Warning: Verification failed for %s",
> ik->external_name());
> CLEAR_PENDING_EXCEPTION;
> SystemDictionaryShared::set_class_has_failed_verification(ik);
> _has_error_classes = true;
> }
> During the processing of the `@lambda-proxy` in the class list, the `ClassListParser::resolve_indy` would be called and the check is for checking if the caller class has failed verification before.
Okay so you're trying to catch a previous link time failure. Why do you expect the next try_link_class call to never fail?
-------------
PR: https://git.openjdk.java.net/jdk16/pull/30
More information about the hotspot-runtime-dev
mailing list