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.


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