java.util.zip throws- oversubscribed dynamic bit lengths tree

[Dave Bristor]

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) 
>>>>>
>>>>
>>>
>