Null dereference when using AppCDS with old classes and VM_RedefineClasses

Calvin Cheung calvin.cheung at oracle.com
Thu Oct 17 22:36:57 UTC 2024


Hi Justin,

Thanks for reporting the bug.

On 10/16/24 3:36 PM, Justin Du wrote:
> Hi everyone,
>
> I recently reported JDK-8342303 [0], where a rare interaction
> between AppCDS and VM_RedefineClasses leads to a null pointer
> dereference. I believe the cause is the following:
>
> 1. At AppCDS dump time, old classes (bytecode version < 50)
>     aren't linked, so their vtables contain all null pointers.
> 2. If we load old class A before the first class redefinition,
>     A's vtable is still uninitialized.
> 3. If we load old class B after the first class redefinition,
>     JvmtiExport::has_redefined_a_class() is true. Then
>     InstanceKlass::restore_unshareable_info reinitializes B's
>     vtable, in case its superclass was redefined.
> 4. If B extends A, then A's uninitialized vtable is copied into
>     B's vtable, leading to a null pointer dereference.
>
> Notably, if B's superclass is already linked when B is loaded,
> then the vtable reinitialization still succeeds.

A workaround is to use Class.forName() to load the superclass (the 
"Animal" class in your test case).

BTW, I've tried your workaround by enabling JFR and it didn't work for 
me with my mainline repo. I haven't tried JDK17.

>
> To prevent this, maybe we only need to reinitialize vtables if
> the class is already linked?

Yes. I've updated the bug report with a potential fix.

Thanks!
Calvin
>
> Thanks!
> Justin
>
> [0] https://bugs.openjdk.org/browse/JDK-8342303


More information about the hotspot-runtime-dev mailing list