Bug 50228

Summary: PermGen leak when calling JspFragment.invoke() with a custom Writer
Product: Tomcat 6 Reporter: Konstantin Kolinko <knst.kolinko>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 6.0.29   
Target Milestone: default   
Hardware: PC   
OS: Windows XP   
Attachments: writerleak.war - Reproduces the leak
Screenshot from Eclipse MAT

Description Konstantin Kolinko 2010-11-07 03:27:43 UTC
Created attachment 26266 [details]
writerleak.war - Reproduces the leak

We have a web application that contains a SimpleTag that calls JspFragment.invoke(writer) with a custom java.io.Writer (actually, a NullWriter from commons-io).

When this application is undeployed, it still remains in memory, as reported by the "Find leaks" tool in the manager webapp.

I am attaching a simple sample application that reproduces the issue.

To reproduce:
1. Deploy the app.
2. Open index.jsp
3. Undeploy the app.
4. "Find leaks" reports that the app is still in memory


Using the Eclipse MAT tool I can see that the leak is caused by o.a.jasper.runtime.BodyContentImpl keeping a reference to the Writer,
while the BodyContentImpl instance is cached in some pool referenced by a ThreadLocal.
Comment 1 Konstantin Kolinko 2010-11-07 03:30:06 UTC
Created attachment 26267 [details]
Screenshot from Eclipse MAT
Comment 2 Konstantin Kolinko 2010-11-07 10:21:27 UTC
Fixed in trunk with r1032232 (will be in 7.0.5), proposed for 6.0.x.
Comment 3 Konstantin Kolinko 2010-11-17 16:01:33 UTC
I will have to revert r1032232 

It breaks evaluation of tag bodies when there is no writer, e.g.
<c:set var="myvar">value<c:set>
MyVar: [${myvar}]

results in "MyVar: []" being printed.


A working fix would be to nullify the writer only if it has been set previously. Maybe there is some better way, though.
Comment 4 Konstantin Kolinko 2010-11-22 12:45:17 UTC
Fixed in trunk with r1037794 (will be in 7.0.5), proposed for 6.0.x.
Comment 5 Konstantin Kolinko 2010-12-01 20:36:53 UTC
Fixed in 6.0 with r1041247 (will be in 6.0.30).