RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with unparseable extensions

Xuelei Fan xuelei.fan at oracle.com
Wed Feb 20 19:28:58 UTC 2019


On 2/20/2019 10:52 AM, Sean Mullan wrote:
> On 2/20/19 1:41 PM, Xuelei Fan wrote:
>> ping ...
> 
> I took a quick look, but not enough time to understand the full context. 
> The exception in the UnparseableExtension can be useful to get a stack 
> trace later of why it could not be parsed. Did you think of any other 
> way you can fix this?
> 
In the UnparseableExtension implementation, the private 'why' variable 
can be used to dump the stack trace later.  But as it is used to get it 
exception message only, I updated to store the exception message only. 
The update does not impact the fix.  It is a kind of DiD fix in case it 
is used in a static field in other places.  We can leave it unchanged if 
you like.

Thanks,
Xuelei

> --Sean
> 
>>
>> On 2/8/2019 12:26 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the following update reviewed?
>>>     http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
>>>
>>> In the lazy initialization holder in SSLContextImpl, an exception is 
>>> reserved as static in order to check if the holder is initialized 
>>> properly.  If the exception had a strong referent to some object, the 
>>> object will be out of the cycle of garbage collection.
>>>
>>> With this update, the original exception is debug logged, and a new 
>>> exception with the same exception message as the original one.
>>>
>>> Code cleanup, no new regression test.
>>>
>>> Thanks & Regards,
>>> Xuelei



More information about the security-dev mailing list