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

Race Condition can cause CacheEntry.getJarSigningData() to return null.

XMLWordPrintable

    • b96
    • Not verified

        CacheEntry.getJarSigningData() checks the SoftReference signingDataRef to get the info for a given cache entry. If the return is null it then computes it from the JarFile directly, and places the result in the signingDataRef, then just a few lines later it returns signingDataRef.get().
        Unfortunately, this means that for a few lines of code there is no hard ref to the computed data, and it may be garbage collected (or explicitly cleared.)
        Instead CacheEntry.getJarSigningData() should compute the JarSigningData and keep it in a local variable until it can return it (also storing it in the softReference).
        This problem is seen intermittently in the CacheJarFileTest unit test.
        although there are other failures in this test, the 2 intermittent Errors caused by a null pointer exception in CachedJarFileTest.runEntryGetCertificates() and CachedJarFileTest.runEntryGetCodeSigniers() are caused by this.
        The tests loop thu the hundreds of entries in a signed jar, and clear the soft references to them both synchronously and asynchronously, and will get an NPE if the call to JarFileEntry.getCodeSigners() returns null.
        I can see this happen about 50% of the time running this test in netbeans, but never with the fix.

        The problem is a regression caused by the fix to JDK-8140400

              herrick Andy Herrick (Inactive)
              herrick Andy Herrick (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: