[
https://issues.apache.org/jira/browse/XERCESJ-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Costanzo updated XERCESJ-1667:
------------------------------------
Fix Version/s: 2.12.0
> ClassLoader memory leak via stacktrace in pre-created DOMNormalizer.abort
> exception
> -----------------------------------------------------------------------------------
>
> Key: XERCESJ-1667
> URL: https://issues.apache.org/jira/browse/XERCESJ-1667
> Project: Xerces2-J
> Issue Type: Bug
> Reporter: Konstantin Kolinko
> Assignee: Michael Glavassevich
> Fix For: 2.12.0
>
>
> Originally reported in Apache Tomcat project,
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58486
> {quote}
> The classes com.sun.org.apache.xerces.internal.dom.DOMNormalizer and
> com.sun.org.apache.xml.internal.serialize.DOMSerializerImpl, both within
> rt.jar, each contain a static final field of type RuntimeException named
> 'abort'. When these classes are statically initialized, these exceptions are
> created and their stacktraces filled in. If a web app class happens to be in
> the call stack when either class's exception is created, this class cannot
> then
> be garbage collected when the web app is stopped because an exception in a
> static field of a class has a reference to it. This then causes a PermGen
> leak
> as the web apps's classloader, and all of the classes it loaded, cannot be
> garbage-collected.
> {quote}
> Looking at Xerces-J trunk, I see the mentioned "abort" field in
> org.apache.xerces.dom.DOMNormalizer class. So the issue is present in Apache
> Xerces-j as well.
> I do not see the field in org.apache.xml.serialize.DOMSerializerImpl. It
> looks as if it was replaced by "DOMNormalizer.abort" one during refactoring.
> We added a code to workaround this issue in Tomcat (effectively: to preload
> those buggy classes, r1710442), but it would be better to fix the original
> culprit.
> A known way to fix such an issue is to create a custom exception class that
> overrides fillInStackTrace() method with an empty implementation.
> There are two examples of such fix in Apache Tomcat.
> 1.
> [org.apache.jasper.compiler.JspDocumentParser$EnableDTDValidationException|http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_28/java/org/apache/jasper/compiler/JspDocumentParser.java?view=markup#l1512]
> 2.
> [org.apache.tomcat.util.buf.UDecoder$DecodeException|http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_28/java/org/apache/tomcat/util/buf/UDecoder.java?view=markup#l46]
> A funny thing is that this solution used in Tomcat actually originates in
> Apache Xerces. So it is a loop here. The old report that triggered this fix
> and discussion is here:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=50460
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
