Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread

[Seán Coffey]

Logged https://bugs.openjdk.java.net/browse/JDK-8156841

Regards,
Sean.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160512/333ab975/attachment.htm>