Harsha Godugu wrote:
Dave Bristor wrote:
Hi Harsha,
Hi Dave,
Unfortunately there is no stand alone reproducible test case. It
appears that 6713913 and the issue I brought up here are related. Out
of curiosity, I was looking into inflater / deflater code to see what it
means to get the ' oversubscribed dynamic bit lengths tree'. According
to the code, it's due to the jar file being not in the right format when
the error occurred. The one thing that's suspicious here is, the jar
file creation. Their build uses maven's internal code to create a jar
file on the fly. (this problem happens consistently on Solaris & mac..
Is it possible to alter the build to use some other form of jar file creation?
Googling shows that there was a problem with zlib 1.1.2 that could cause the
particular "oversubscribed dynamic bit lengths tree" message, but that this
was fixed in zlib 1.1.3, which is what the JDK uses. Is it possible that
maven has its own implementation of zip code? I know that ant does; they rely
on some of the java.util.zip API but have their own code to read and write ZIP
files. I see that maven's sources include "maven-ant-tasks-2.0.8.jar". If
maven is using ant's ZIP code, perhaps the problem lies there. Could you check?
with that build.) If there is a jar file (format) verifier to examine
each bit of the (created) jar, then that would help nail down this
% zip
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
Zip 2.3 (November 29th 1999). Usage:
...
-T test zipfile integrity
% unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]
Default action is to extract files in list, except those in xlist, to exdir;
file[.zip] may be a wildcard. -Z => ZipInfo mode ("unzip -Z" for usage).
...
-t test compressed archive data
However, Sahoo provided a jar that caused a failure during build, and it
passes the above checks. So I don't know how thorough the above are.
Googling shows a few integrity checking tools, mostly for Windows.
problem. Would it also be a problem, if multiple threads accessing
As long as they're all reading, I believe it should not be a problem. If
there is a writer and N readers which are using the stream classes, and they
are properly synchronized, this should also work.
Thanks,
Dave
(reading ) the same jar? (Or any other jar related flags that could be
enabled to check the integrity of the jar would be of help here.)
I will add the stack traces to the same bug report.
thanks,
Harsha
One data point to not
Do you have a reproducible testcase? This appeared years before my
time, see 4188883, "java.util.zip.ZipException: oversubscribed dynamic
bit lengths tree", and was closed with the note "Irreproducible -
probably fixed some time ago."
Sahoo has filed 6713913, "Fatal errors during jar file processing",
but I'm unable to reproduce the problem.
Thanks,
Dave
thanks,
Harsha
Problem: When reading large jar files programatically, we get the
following exception.
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
assembling JAR
at
com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183)
at
com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: java.util.zip.ZipException: oversubscribed dynamic bit
lengths tree
at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
at java.io.DataInputStream.readFully(DataInputStream.java:176)
at java.util.jar.JarFile.getBytes(JarFile.java:364)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
at java.util.jar.JarFile.getManifest(JarFile.java:145)
at
com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172)
at
com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126)
at
com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168)
