Uploaded image for project: 'Xerces2-J'
  1. Xerces2-J
  2. XERCESJ-1667

ClassLoader memory leak via stacktrace in pre-created DOMNormalizer.abort exception

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.12.0
    • Component/s: None
    • Labels:
      None

      Description

      Originally reported in Apache Tomcat project,
      https://bz.apache.org/bugzilla/show_bug.cgi?id=58486

      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.

      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

      2. org.apache.tomcat.util.buf.UDecoder$DecodeException

      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

        Attachments

          Activity

            People

            • Assignee:
              mrglavas@ca.ibm.com Michael Glavassevich
              Reporter:
              kkolinko Konstantin Kolinko
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: