Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
Mark Thomas
markt at apache.org
Thu May 12 12:50:17 UTC 2016
On 12/05/2016 12:40, Seán Coffey wrote:
> Logged https://bugs.openjdk.java.net/browse/JDK-8156841
>
> Regards,
> Sean.
Many thanks,
Mark
>
> On 10/05/2016 14:51, Mark Thomas wrote:
>> Hi,
>>
>> While working my way through Tomcat's memory leak protection / detection
>> / fixing code, I have found an issue that remains unresolved in the
>> latest JDK 9 source.
>>
>> The poller thread created by the SunPKCS11 class does not explicitly set
>> the context class loader so it inherits the current context class
>> loader. If the current context class loader when this code is triggered
>> happens to be one that is meant to be disposable (e.g. a web application
>> class loader) the class loader will be pinned in memory until the Thread
>> stops. This prevents the class loader from being GC'd when no longer
>> required and triggers a mmeory leak.
>>
>> Given that the creation of this thread depends on various factors,
>> including hardware configuration, the issue is fairly rare but we have
>> seen instances of it reported [1].
>>
>> The fix looks to be trivial. Something along the lines of the following
>> around line 820 of SunPKCS11:
>>
>> t.setContextClassLoader(SunPKCS11.class.getClassLoader());
>>
>> If I can provide any further information or if there is better place /
>> way to submit this then please do let me know.
>>
>> Mark
>>
>> [1] http://markmail.org/message/sykuo32eeknwsaqk
>
More information about the security-dev
mailing list