You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org> on 2015/10/26 21:52:27 UTC
[jira] [Resolved] (XERCESJ-1667) ClassLoader memory leak via
stacktrace in pre-created DOMNormalizer.abort exception
[ https://issues.apache.org/jira/browse/XERCESJ-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Glavassevich resolved XERCESJ-1667.
-------------------------------------------
Resolution: Fixed
Also a funny thing... I wrote the original fix in Xerces. Must not have realized at the time that there was another instance of this "abort" exception. Fixed now in SVN rev 1710695.
> 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
>
> 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