Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
Subject: [Bug 53935] New: Minimize classloader leaks from stacktrace elements
 in long-lived Exceptions
Date: Mon, 01 Oct 2012 08:02:24 +0000
Message-ID: <bug-53935-78@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
MIME-Version: 1.0

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 <markt@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