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

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

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.12.0
    • None
    • 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

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

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

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment