RFR (S) 8218851: JVM crash in custom classloader stress test, JDK 12 & 13

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri Feb 15 13:35:00 UTC 2019



On 2/15/19 8:26 AM, David Holmes wrote:
> On 15/02/2019 10:04 pm, coleen.phillimore at oracle.com wrote:
>> On 2/14/19 8:54 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 15/02/2019 2:58 am, coleen.phillimore at oracle.com wrote:
>>>> Summary: Handle NULL and unloaded constraint class in loader 
>>>> constraint table, also cope with unloaded but not cleaned out klass 
>>>> in loader constraint entries.
>>>
>>> Pardon my ignorance but how can an unloaded class still be involved 
>>> in a loader constraint?
>>
>> The class can be not loaded yet, because we apparently add the klass 
>> to the loader constraint table before the is_loaded flag is set.  It 
>> can be already unloaded with concurrent class unloading because the 
>> table hasn't been cleaned out yet.   I put interesting bits of the 
>> stack trace in the bug report.
>
> That sounds really racy. So if we do the check before is_loaded is set 
> it passes or fails? And if we do the check a millisecond later when 
> is_loaded is set, it passes or fails? Surely there has to be some 
> atomicity here.

The loader constraint table is examined under the SystemDictionary_lock, 
and the is_loaded flag on an InstanceKlass is also.   The loader 
constraint table checks the constraints whether it's fully loaded or 
not, because it just compares the _klass.  This is the existing code.  
The error message is new and didn't have a NULL check for the return for 
the find_constrained_klass().  This could have failed without ZGC, 
except we didn't get it to reproduce.

There are two issues here, I'm not sure which one you are worried about.

thanks,
Coleen

>
> David
>> thanks,
>> Coleen
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Tested overnight with the application that caused the crash.  
>>>> Tested with hs tier1-6.   Tested JCKs with ZGC.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8218851.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8218851
>>>>
>>>> Thanks,
>>>> Coleen
>>



More information about the hotspot-runtime-dev mailing list