Memory leak in com.sun.jndi.ldap.pool.PoolCleaner

Mark Thomas markt at apache.org
Wed May 11 11:18:55 UTC 2016


On 11/05/2016 08:18, Alan Bateman wrote:
> On 10/05/2016 23:05, 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 PoolCleaner thread started by the LdapPoolManager when the idle
>> timeout is positive 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.
>>
>> The fix looks to be trivial. Something along the lines of the following
>> around line 45 of PoolCleaner:
>>
>> setContextClassLoader(PoolCleaner.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.
>>
> This may be a case where it should be using an InnocuousThread but
> requires more study as it's very old code.
> 
> Can you submit a bug for this?
> 
> -Alan

Sure. Done.
Review ID: 9087338

Thanks,

Mark



More information about the core-libs-dev mailing list