Bug 49292 - Memory leak in org.apache.taglibs.standard.lang.jstl.ELEvaluator
Summary: Memory leak in org.apache.taglibs.standard.lang.jstl.ELEvaluator
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.1
Hardware: PC Windows Server 2003
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-05-14 10:52 UTC by pmd1nh-rm
Modified: 2010-10-11 22:58 UTC (History)
0 users

Snapshot shows large entries in the Map (137.23 KB, image/jpeg)
2010-05-14 10:52 UTC, pmd1nh-rm
standard.1.0.6 patched for j2se 1.4 (529.39 KB, application/java-archive)
2010-05-19 11:35 UTC, nebur43
snapshot of ELEvaluator direct children (117.69 KB, image/jpeg)
2010-05-19 16:26 UTC, pmd1nh-rm
snapshot new ELEvaluator (167.28 KB, image/jpeg)
2010-05-20 05:38 UTC, nebur43

Note You need to log in before you can comment on or make changes to this bug.
Description pmd1nh-rm 2010-05-14 10:52:23 UTC
Created attachment 25438 [details]
Snapshot shows large entries in the Map


I got an OOM and Eclipse MAT shows a potential leak in the org.apache.taglibs.standard.lang.jstl.ELEvaluator.
There was a memory leak in this area and fixed via revision 580198 (Bug 31789 
http://issues.apache.org/bugzilla/show_bug.cgi?id=31789).  This fix has already been pulled into our standard.jar bundle.

I use the default exprCacheSize which is 100.  So the LRUMap size would be expected to be max out at 100.  However, the heapdump during the OOM shows that there was 1.8 million entries in the map (screenshot is attached).

Is there any potential or known issue in this LRUMap?

Comment 1 nebur43 2010-05-19 11:27:00 UTC

Are you sure apply correctly the patch? These patch is must be apply not in root path, also in \src\org\apache\taglibs\standard.

And extra/collections package must be move to extra\commons\collections before running ant. (the patch is a little confusing).

Could you attach a memory snapshot for all direct ELEvaluator childrens?
Comment 2 nebur43 2010-05-19 11:35:08 UTC
Created attachment 25456 [details]
standard.1.0.6 patched for j2se 1.4

Attached the standard.jar with the patch
Comment 3 pmd1nh-rm 2010-05-19 16:26:08 UTC
Created attachment 25458 [details]
snapshot of ELEvaluator direct children
Comment 4 pmd1nh-rm 2010-05-19 16:27:28 UTC

Yes, I'm sure that the patch has been applied correctly.  I have also downloaded your attachment of standard-1.0.6, decompiled, and compared with ours.  They are same (from the main fixes in lang.jstl.ELEvaluator and Evaluator to the extra files in extra.commons.collections.*).  I attached the snapshot of ELEvaluator's direct children

Comment 5 nebur43 2010-05-20 05:35:34 UTC
Hi again,

I just have tested the jar and seems to work correctly. 

Sorry, but your jar seems not to be correctly. In your first snapshot you can see these:

 - ELEvaluator
    - Colletions
            -.... lots of HashMap

In my snapshot I attach today, yo can see:

  - ELEvaluator
    - Colletions
            - AbstractHasedMap
            - 79 AbstractLinkedMap

So you are using the old ELEvaluator. Be sure your ELEvaluator are in:


and not in:


Or if you prefer, test my jar file.
Comment 6 nebur43 2010-05-20 05:38:46 UTC
Created attachment 25461 [details]
snapshot new ELEvaluator
Comment 7 pmd1nh-rm 2010-05-20 13:10:05 UTC

Can you please share the application/JSP source that you used to test this?  I don't have a test case for this as the dump was sent in by one of our customers. 

Thank you for your help!
Comment 8 nebur43 2010-05-21 05:31:15 UTC
Sorry, I dont have any test case. I tested it in our aplication.
Comment 9 Henri Yandell 2010-06-29 03:44:14 UTC
Noting that we just dropped the LRUMap code in trunk and replaced it with a JDK 1.5 class (LinkedHashMap). 

Looking at the comments, it looks as though the issue was resolved as a no-issue? Patch not applied on jar?

If still an issue, retrying with trunk (JSTL 1.2) would be valuable. Let me know if you need a build uploaded.
Comment 10 pmd1nh-rm 2010-06-29 10:47:28 UTC

User's app overwrites our jar and causes this issue.

Please close down this thread.  Thank you very much for your help!

Comment 11 Jeremy Boynes 2010-10-11 22:58:22 UTC
Resolving as per comment 10 this appears to be a user issue