United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6957028 : Random SHA1 digest errors when using Java Web Start with JarDiff

Details
Type:
Bug
Submit Date:
2010-05-28
Status:
Closed
Updated Date:
2013-12-27
Project Name:
JDK
Resolved Date:
2012-08-01
Component:
deploy
OS:
windows_vista,windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u20,6u23,6u34,7u6,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Apache Tomcat/6.0.20

A DESCRIPTION OF THE PROBLEM :
Our application is deployed using Java Web Start with the JNLP servlet. For new versions we use the JarDiff feature to keep the download size small. When JRE 1.6.0_20 is used to launch a new version of the application, Java Web Start will often fail with "SHA1 digest errors" for random files inside JarDiff patched Jars. When trying to launch the application a second time, it usually works.

The failure occurs for different files in different Jars each time I reproduce the error, even though I use the same Wars each time to deploy the two application versions in my tests. It is not always a .class file, but errors are reported for .properties and .png files as well.

The error is not reproducible if I use JRE 1.6.0_16 to launch the application.

Other users seem to be affected as well. I found this forum entry http://forums.sun.com/thread.jspa?messageID=10974681 which discusses this problem.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. deploy a signed Java Web Start application using the JNLP servlet.
2. launch the application using JRE 1.6.0_20 to fill the Web Start cache.
3. deploy a new version of the application such that the JarDiff feature of the JNLP servlet is used.
4. launch the application using JRE 1.6.0_20.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application launches without errors.
ACTUAL -
Java Web Start reports Application Error "Unable to start the Application", wrapped exception is "SHA1 digest error" for a random file.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: (http://localhost:8081/sseclient/sseclient-jar.jar?version-id=2.57.1-May10.2-2009-2010&current-version-id=2.56.1-Mar22.2-2009-2010, 2.57.1-May10.2-2009-2010)
	at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.getCacheEntry(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$DownloadTask.call(Unknown Source)
	at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Wrapped Exception:
java.lang.SecurityException: SHA1 digest error for com/oneandone/ocis/stg/io/ConfigWriter.class
	at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
	at java.util.jar.JarVerifier.processEntry(Unknown Source)
	at java.util.jar.JarVerifier.update(Unknown Source)
	at java.util.jar.JarVerifier$VerifierStream.read(Unknown Source)
	at java.io.InputStream.read(Unknown Source)
	at com.sun.deploy.jardiff.JarDiffPatcher.writeEntry(Unknown Source)
	at com.sun.deploy.jardiff.JarDiffPatcher.writeEntry(Unknown Source)
	at com.sun.deploy.jardiff.JarDiffPatcher.applyPatch(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.applyPatch(Unknown Source)
	at com.sun.deploy.cache.CacheEntry.processTempDataFile(Unknown Source)
	at com.sun.deploy.cache.Cache.downloadResourceToTempFile(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.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$DownloadTask.call(Unknown Source)
	at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
* Use JRE 1.6.0_16 which is not affected.
* When launching the application again, it usually succeeds.
Additional details from another user with the same problem:
======
We first noticed this bug with version 1.6.0_18. 1.6.0_17 was the last release  
that doesn't show this bug. The current version 1.6.0_33 still exhibits this    
bug.
I think the best chance to reproduce this bug is to try it with a complex       
real-world app, but I don't know if you have such an webstart-enabled app at    
Oracle.
Here are some characteristics of our app:
We have more than 60 third-party JARS in our JNLP file referenced (Spring,      
Apache Commons, Hibernate, JIDE ...). These are not downloaded with JarDiff,    
e.g. they have no version attribute in the JNLP. Only our 10+ self-made JARS    
are versioned, e.g. JarDiff-enabled.
Every time we release a new version, we observe bug 6957028 with JRE versions   
> 1.6.0_17. Most of our customers use Windows XP/Vista/7. For example, I     
observe the bug with Windows 7 64-bit and Firefox 13 32-bit with JDK 1.6.0_33   
64-bit and 32-bit installed.

                                    

Comments
verified with jre8 b108
                                     
2013-12-27
EVALUATION

Justification for 7u6 critical request:
- This is one of the most voted for bugs and is the one with many customer account requests.
- The fix is simple and straight-forward: do not use static modifier on a field that is meant for use by each instance of the class.
                                     
2012-07-27
EVALUATION

I could not reproduce this through multiple run of a simple jar.  Will need to confirm with customer if most recent 6u32 or 7u6 has fixed this behavior.

Codewise, the JarDiffPatcher is kind of independent implementation and does not depends on deploy code other than the progress delegate.  It use JarFile directly and virtually does not change from 6u15, where as the reported incidents seems to pin point 6u18.

Also, the nature of the failure is random which seems to point to threading issue, but reviewing deploy code (JarDiffPatcher and DownloadEngine that initiate the patching) I don't see any possible synchronization problem.
Reviewing JDK code history (ManifestEntryVerifier), I could see that CR 6998860 could be a potential match for this failure pattern.
                                     
2012-06-22
EVALUATION

This fix probably require about 3-day work.  I need setup for jnlp-servlet app.
                                     
2011-02-09
EVALUATION

Possibly JarrDiffPatcher is unstable when used from multiple threads? 
Or may be security validation can not be concurrent?
                                     
2010-11-17



Hardware and Software, Engineered to Work Together