JDK-6541319 : PIT: Jaws hangs on the first lunch of damaged_signed_test.jnlp
Type:Bug
Component:deploy
Sub-Component:webstart
Affected Version:7
Priority:P2
Status:Closed
Resolution:Fixed
OS:windows
CPU:x86
Submitted:2007-04-02
Updated:2011-03-08
Resolved:2011-03-08
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.
Jaws hangs on the first lunch of damaged_signed_test.jnlp
It is a regression, latest promoted build is fine
To reproduce it, launch this test
http://nicole1.sfbay.sun.com:8080/JavawsJDK7IntegTest/certificate/damaged_signed_test.jnlp
EVALUATION
From Thomas Ng:
This is an regression caused by
6518576: Graphics icon not displayed while Java Web Start launch an application with JDK 6.
We are trying to remove a JAR file, but the JAR is not closed yet, and hence when we try to remove it, we got the exception with the new FileLock code:
java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown Source)
at sun.nio.ch.FileChannelImpl.lock(Unknown Source)
at com.sun.deploy.cache.CacheEntry.lockFile(Unknown Source)
at com.sun.deploy.cache.CacheEntry.readManifest(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$300(Unknown Source)
at com.sun.deploy.cache.CacheEntry$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.getJarFile(Unknown Source)
at com.sun.deploy.cache.Cache.removeCacheEntryImpl(Unknown Source)
at com.sun.deploy.cache.Cache.access$100(Unknown Source)
at com.sun.deploy.cache.Cache$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.Cache.removeCacheEntry(Unknown Source)
at com.sun.deploy.cache.Cache.removeCacheEntry(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
at com.sun.javaws.Launcher.downloadResources(Unknown Source)
at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
CacheEntry.lockFile is spinning, hoping it will be able to get the lock sometime, which it won't, and therefore the hang.
This is because in CacheEntry.writeFileToDisk, once we got the badcert exception, we try to remove the bad jar, without actually closing it first. So with the new locking code, we run into the hang.
I have a simple fix available. In CacheEntry.writeFileToDisk, once we got the exception, we should close the JAR before we try to remove the JAR.
Please file a new bug for this. We need to put in a fix for both 6u2 b02 and JDK 7.