Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8156841

sun.security.pkcs11.SunPKCS11 poller thread retains a strong reference to the context class loader

XMLWordPrintable

    • b133
    • generic
    • generic
    • Not verified

      OpenJDK reported issue - http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

      While working my way through Tomcat's memory leak protection / detection/ fixing code, I have found an issue that remains unresolved in the latest JDK 9 source.

      The poller thread created by the SunPKCS11 class does not explicitly set
      the context class loader so it inherits the current context class
      loader. If the current context class loader when this code is triggered
      happens to be one that is meant to be disposable (e.g. a web application
      class loader) the class loader will be pinned in memory until the Thread
      stops. This prevents the class loader from being GC'd when no longer
      required and triggers a memory leak.

      Given that the creation of this thread depends on various factors,
      including hardware configuration, the issue is fairly rare but we have
      seen instances of it reported [1].

      The fix looks to be trivial. Something along the lines of the following
      around line 820 of SunPKCS11:

      t.setContextClassLoader(SunPKCS11.class.getClassLoader());

      If I can provide any further information or if there is better place /
      way to submit this then please do let me know.

      Mark

      [1] http://markmail.org/message/sykuo32eeknwsaqk

            chegar Chris Hegarty
            coffeys Sean Coffey
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: