Bug ID: JDK-8163845 CachedJarFile.getManifest throws UnsupportedOperationException (Collections$UnmodifiableMap.remove)

JDK-8163845 : CachedJarFile.getManifest throws UnsupportedOperationException (Collections$UnmodifiableMap.remove)

Type: Bug
Component: deploy
Sub-Component: webstart
Affected Version: 8u101,9

Priority: P3
Status: Closed
Resolution: Cannot Reproduce
OS: windows_7
CPU: x86_64

Submitted: 2016-08-03
Updated: 2021-05-06
Resolved: 2021-05-06

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 8
8-poolResolved

Related Reports

Duplicate :	JDK-8192055 - CachedJarFile.getManifest throws UnsupportedOperationException (Collections$UnmodifiableMap.remove)
Relates :	JDK-8155076 - Webstart loads JARs from MANIFEST.MF after loading the jars from resources-tag

Description

FULL PRODUCT VERSION :
C:\Windows\System32>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
C:\Windows\System32>ver
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
This appears to be related to the fix for JDK bug https://bugs.openjdk.java.net/browse/JDK-8155076. The above seems to have been fixed but has caused this UnsupportedOperationException to occaisionally occur. We have not been able to firmly identify the root cause yet but believe it is due to the garbage collection of weak-references.

java.lang.UnsupportedOperationException: null
	at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]
	at java.util.jar.Attributes.remove(Unknown Source) ~[na:1.8.0_101]
	at com.sun.deploy.cache.CachedJarFile.getManifest(Unknown Source) ~[na:na]
	at com.sun.deploy.security.DeployURLClassPath$JarLoader$2.getManifest(Unknown Source) ~[na:na]
	at java.net.URLClassLoader.defineClass(Unknown Source) ~[na:1.8.0_101]
	at java.net.URLClassLoader.access$100(Unknown Source) ~[na:1.8.0_101]
	at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
	at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
	at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_101]
	at java.net.URLClassLoader.findClass(Unknown Source) ~[na:1.8.0_101]
	at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) ~[na:na]
	at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]
	at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source) ~[na:na]
	at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]

Has occurred once in QA (but has not been reproducible), and 2 customers have reported it too since upgrading to 8u101.

REGRESSION.  Last worked in version 8u91

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We are still working to reproduce - will update this if/when we can. We believe the cause is related to garbage collection of the weak-reference (CachedJarFile.manifestRef).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
CachedJarFile.getManifest should successfully return the manifest, not throw an exception.
ACTUAL -
java.lang.UnsupportedOperationException: null
	at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]

ERROR MESSAGES/STACK TRACES THAT OCCUR :
See above.

REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------
Still working on this.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Looking at preventing the garbage collection of the manifestRef by establishing a hard-link to it.

Comments

Adding update shared by submitter through another report: =========================================== This is a duplicate of https://bugs.openjdk.java.net/browse/JDK-8163845 but that issue was wrongly closed. The issue occurs when the JVM is low on memory. The issue does exists in JDK 8u152 and 9.0.1 as well. After decompiling deploy.jar, I deduced that the issue occurs after the ImmutableManifest referenced by com.sun.deploy.cache.CachedJarFile.manifestRef (SoftReference) is garbage collected, but the underlying Manifest referenced by java.util.jar.JarFile.manRef has not been garbage collected. When CachedJarFile#getManifest() is called, CachedJarFile.manifestRef.get() returns null, but super.getManifest() (JarFile#getManifest()) returns the underlying Manifest (JarFile.manRef), whose Manifest.attr.map has been changed into a Collections.UnmodifiableMap by ImmutableManifest#replaceAttributesMapWithImmutableMap(Attributes) via Reflection. CachedJarFile#getManifest() then calls Manifest.getMainAttributes()#remove(Object), which throws UnsupportedOperationException because Attributes.map has been replaced with a Collections.UnmodifiableMap. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : Difficult to reproduce because of the conditions required to simulate this issue. ERROR MESSAGES/STACK TRACES THAT OCCUR : java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Unknown Source) at java.util.jar.Attributes.remove(Unknown Source) at com.sun.deploy.cache.CachedJarFile.getManifest(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader$2.getManifest(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) =============================================== Additional note from submitter: JDK-8163845 was wrongly closed so that this bug would not be closed as a duplicate of JDK-8163845. JDK-8163845 was wrongly closed as a duplicate of JDK-8155076. But JDK-8155076 did not fix JDK-8163845, instead the fix for JDK-8155076 is what caused JDK-8163845. I have given the exact code in the source code that causes this bug, and the exact conditions required for the bug to occur.

29-11-2017

Submitter Response ------------------------------------------ There is no easily reproducible test case so far, although its believed that such a case might be along the lines of - https://forums.oracle.com/forums/thread.jspa?threadID=2148354 and JDK-6967414 since these bugs are where all these soft-referenced classLoader issues first got reported and supposedly resolved but obviously not completely. Will update as we find a reproducible. ------------------------------------------

12-08-2016

According to the description the fix in JDK-8155076 has caused occasional java.lang.UnsupportedOperationException likely due to collection of weak references. Checking for a test case scenario with submitter to reproduce the issue.

11-08-2016