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

[David Holmes]

On 15/02/2019 11:35 pm, coleen.phillimore at oracle.com wrote:
> 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.

I'm not sure either. I guess I don't understand how NULL can be 
appearing in this context. I know you explained it but I don't see how 
it makes sense conceptually. This just seems racy.

I have to call it a night. :)

Cheers,
David

> 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
>>>
>