RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with unparseable extensions

[Sean Mullan]

On 2/20/19 2:28 PM, Xuelei Fan wrote:
> 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.

Actually I took another closer look at the code and I am ok with your 
change since you can always get the stack trace if you reparse the cert 
and enable debugging.

--Sean

> 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