Hi! I was reviewing the reproduction recipe for java bug 6916498 [1] and came to a conclusion that it is triggered by the following line in one of the classes (see my comment in [1] for details):
public static final RuntimeException abort = new RuntimeException(); [1] "Class loader leak goes unreported via JVMTI" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6916498 The leak happens when the stacktrace includes classes loaded by webapp's classloader. It is understandable. The problem is that those references are not visible in a profiler, e.g. in Eclipse MAT. I do not know how to obtain a list of all Exceptions that are present in memory, but the following recipe is good for most cases. In Eclipse MAT: 1. Open a heap dump 2. Click "Open Query Browser" button on the toolbar. A menu appears. 3. Select "List objects" -> "with incoming references" 4. Type the following expression as the class name: .*Exception That will list all classes whose name ends with "Exception". Additional notes: 1) The offending class in [1] is AbstractDOMParser, copied from Apache Xerces. The current code of Xerces is different [2]. The current code looks better, but I have not tested whether that fixes the leak or not. [2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/parsers/AbstractDOMParser.java?annotate=782187#l162 2) I found a scenario when such a leak is caused by a field in org.apache.jasper.compiler.JspDocumentParser. I will add an issue into Bugzilla. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org