Bug 48837 - Memory leaks protection does not detect leaks triggered by JSP pages code
Summary: Memory leaks protection does not detect leaks triggered by JSP pages code
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-01 18:51 UTC by Konstantin Kolinko
Modified: 2010-12-01 21:30 UTC (History)
0 users



Attachments
webapps/examples/foo.jsp (318 bytes, application/octet-stream)
2010-03-01 18:51 UTC, Konstantin Kolinko
Details
Patch to enhance classloader leaks because of uncleared ThreadLocal (3.67 KB, patch)
2010-03-11 21:46 UTC, Sylvain Laurent
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2010-03-01 18:51:11 UTC
Created attachment 25077 [details]
webapps/examples/foo.jsp

The memory leaks protection feature of TC6/TC7 is able to heal certain types of memory leaks caused by servlet code (where classes are loaded by WebappClassLoader), but does not provide a cure for ones caused by JSP code (where classes are loaded by JasperLoader).

I think that is of little concern, as the code that triggers a memory leak is unlikely to be present on a JSP page or a tag file, but at least it provides us with an example to test the "Find leaks" diagnostics in the Manager webapp.


To reproduce:
1. Place the attached foo.jsp into the examples webapp
2. Open http://localhost:8080/examples/foo.jsp
3. Open the Manager web application
4. Reload or stop/start the examples application
5. Press the "Find leaks" button in the Manager
6. The message will be displayed that "/examples" app triggered a memory leak.

The leak is caused by foo.jsp creating a ThreadLocal holding an instance of some inner class of that JSP. (That inner class was loaded through JasperLoader, and thus was not detected when enumerating ThreadLocals in leaks protection code.)

7. Another ThreadLocal (holding a reference to some servlet) is successfully cleared by memory leak protection code when the examples application is stopped. You can see a message about that in the Tomcat logs.
Comment 1 Sylvain Laurent 2010-03-11 21:46:46 UTC
Created attachment 25116 [details]
Patch to enhance classloader leaks because of uncleared ThreadLocal

Proposing a patch to better detect leaks. Before the patch, the leak caused by an uncleared ThreadLocal is detected only if the ThreadLocal key or value is loaded by the WebAppClassLoader.
The patch proposes to also detect cases where the key or value object class was loaded by a child classloader (or any level of descendant).

The leak of the example foo.jsp is detected (and cleared) with this patch.

Note that there's still a leak if the key or value is a JDK class like an ArrayList which itself contains an instance of a class loaded by the WebAppClassLoader (or a child classloader).

Sylvain
Comment 2 Mark Thomas 2010-11-24 16:34:32 UTC
Fixed in 7.0.x and will be included in 7.0.6 onwards. I also proposed your patch for 6.0.x
Comment 3 Sylvain Laurent 2010-11-25 16:31:10 UTC
Thanks Mark.
Just to clarify things : the patch just improves the detection of such leaks.
To cure them (besides fixing the webapp code), you'll have to enable the (unsafe) clearReferencesThreadLocals option on the StandardContext or wait for bug 49159 to be fixed.
Comment 4 Konstantin Kolinko 2010-12-01 21:30:01 UTC
Fixed in 6.0 by r1041255 (will be in 6.0.30 onwards).