Bug 57939 - Classloader leak in org.apache.naming.ContextBindings
Classloader leak in org.apache.naming.ContextBindings
Product: Tomcat 8
Classification: Unclassified
Component: Catalina
PC Mac OS X 10.1
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2015-05-20 09:10 UTC by Nikita Salnikov-Tarnovski
Modified: 2015-05-27 07:14 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Salnikov-Tarnovski 2015-05-20 09:10:58 UTC
This is kind of a follow up on https://bz.apache.org/bugzilla/show_bug.cgi?id=56275.

We get reports from some of our clients using Tomcat 8 (specific version is unknown) regarding class loader leak via "clBindings" field of "org.apache.naming.ContextBindings" where some "org.apache.catalina.loader.WebappClassLoader" are used as keys in that map and are not cleaned after application's undeploy. It seems that similar bug was fixed in Tomcat 6 and 7, but almost the same bug was introduced in Tomcat 8.
Comment 1 Mark Thomas 2015-05-22 14:47:31 UTC
This is a symptom of a different problem. It can happen if an uncaught exception is thrown by an earlier LifecycleListener. You'll probably want to speak to your clients to find out what went wrong that triggered the earlier failure.

I'll look add catching and logging such errors to stop them propagating but generally these sorts of errors are indications that something is broken somewhere.
Comment 2 Mark Thomas 2015-05-22 15:09:08 UTC
Exceptions will be caught and logged from 8.0.24 onwards.
Comment 3 Rainer Jung 2015-05-23 15:58:11 UTC
The fix had to be reverted. Another fix is needed.
Comment 4 Mark Thomas 2015-05-27 07:14:51 UTC
The original fix (log a lifecycle listener exception and continue) didn't work since lifecycle exceptions are expected to be fatal.

I've taken a longer look at the code and an exception in a lifcycle listener is still the only way I can see this happening. That should result in at least one log entry with a stack trace and the web application ending up in the failed state. Under these conditions, a memory leak isn't a surprise and it is the root cause (of the failed lifecycle listener) that needs to be addressed.

For now I am reslving this as invalid but please feel free to re-open this issue if any of the following are the case:
- no stack trace is logged (with default logging levels)
- the web application is not marked as failed
- the error is recoverable but the memory leak remains

For any of these please provide the exact steps to reproduce the error form a clean install of the latest stable Tomcat 8 release. If a web applciation is required to reproduce it, please keep the web application as simple as possible.