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