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

David Holmes david.holmes at oracle.com
Fri Feb 15 13:26:05 UTC 2019


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.

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