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 2012/10/01 10:02:24 UTC
[Bug 53935] New: Minimize classloader leaks from stacktrace elements
in long-lived Exceptions
https://issues.apache.org/bugzilla/show_bug.cgi?id=53935
Priority: P2
Bug ID: 53935
Assignee: dev@tomcat.apache.org
Summary: Minimize classloader leaks from stacktrace elements in
long-lived Exceptions
Severity: enhancement
Classification: Unclassified
OS: Windows NT
Reporter: timo.kinnunen@gmail.com
Hardware: PC
Status: RESOLVED
Version: unspecified
Component: Catalina
Product: Tomcat 7
Status: RESOLVED
Resolution: DUPLICATE
MemoryLeakProtection in the Tomcat wiki says: "Sun bug 6916498 - An exception
can keep a classloader in memory if the stack trace that was recorded when it
was created contains a reference to one of its classes." This bug may be
considered an acceptable performance tradeoff, so detection and mitigation in
the meantime is in my opinion desirable.
The leak is caused by a reference cycle that is only partially visible to the
garbage collector. The method fillInStackTrace() can be called on an Exception
object to alter its stacktrace, but to effectively break the cycle the method
call chain up to that point must be clean of any classes that shouldn't be
retained.
The attached test code contains two versions of the algorithm, for Java 1.6 and
1.7. The 1.6 version is intended to be effective only when loaded by a shared
classloader, the 1.7 version should be effective even if loaded by a webapp
classloader.
The methods are intended to be called before or during webapp
unloading/reloading on Exception objects stored in static variables.
Please review to see if I've made any mistakes and consider for enhancement :)
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
*** This bug has been marked as a duplicate of bug 53936 ***
--
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