You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2014/03/17 10:14:26 UTC
[Bug 56275] New: Classloader leak in DirContextURLStreamHandler
https://issues.apache.org/bugzilla/show_bug.cgi?id=56275
Bug ID: 56275
Summary: Classloader leak in DirContextURLStreamHandler
Product: Tomcat 6
Version: unspecified
Hardware: All
OS: Mac OS X 10.4
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: nikita@plumbr.eu
I am a developer of the tool named Plumbr, which detects memory leaks in user
applications. Quite a few of our clients got reports about WebappClassLoader
being retained after application undeploy. Classloader is retained in
"clBindings" static field of
org.apache.naming.resources.DirContextURLStreamHandler class. This prevents
application's class loader from being garbage collected and eventually leads to
OutOfMemoryError: PermGen.
Unfortunately, I have no steps to reproduce the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 56275] Classloader leak in DirContextURLStreamHandler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56275
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Mark Thomas <ma...@apache.org> ---
This has been fixed in 6.0.x and will be included in 6.0.40 onwards.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 56275] Classloader leak in DirContextURLStreamHandler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56275
--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Confirmed. A filter that throws an unchecked exception on destroy can trigger
this. This issue has been fixed in 7.0.x. I'll look at putting together a
proposal to back-port the changes to 6.0.x
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 56275] Classloader leak in DirContextURLStreamHandler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56275
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
I've back-ported the fix and tested that it works. The fix has been proposed
for 6.0.x.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 56275] Classloader leak in DirContextURLStreamHandler
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56275
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
Hmm. For this to happen an exception would have to be thrown during web
application stop that prevented the code that de-registers the associated class
loader from being called.
8.0.x is immune to this issue because the registration and deregistration code
has been removed as part of the refactoring of resource handling.
I've been through the 7.0.x code and I can't see any obvious way to trigger
this. All the obvious exceptions that could trigger the problem are caught,
logged and not re-thrown. The only exceptions excluded from the process are
fatal to the JVM anyway.
I do see a possible way to trigger this memory leak in 6.0.x but I need to do
some testing to confirm it.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org