[jira] [Created] (XERCESJ-1667) ClassLoader memory leak via stacktrace in pre-created DOMNormalizer.abort exception

["Konstantin Kolinko (JIRA)" <xe...@xml.apache.org>]

Konstantin Kolinko created XERCESJ-1667:
-------------------------------------------

             Summary: 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


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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org