I will attach a sample zip file which contains an empty file slight under 50MB. Sample code: import java.io.File; import java.util.zip.ZipEntry; import java.util.zip.ZipFile; import junit.framework.TestCase; import org.apache.commons.io.IOUtils; public class TestZipBug extends TestCase { public void testZipBug() throws Exception { ZipFile zip = new ZipFile(new File("D:\\gnu-zip-large-file-bug.zip")); ZipEntry entry = (ZipEntry) zip.entries().nextElement(); IOUtils.toByteArray(zip.getInputStream(entry)); // Omitting code to verify contents. } } Resulting error: Caused by: gnu.java.util.zip.ZipException: Code lengths don't add up properly. at gnu.java.util.zip.InflaterInputStream.read(Unknown Source) at java.io.FilterInputStream.read(FilterInputStream.java:90)
Created attachment 15777 [details] gnu-zip-large-file-bug.zip Attaching test file.
It appears that the code != 65536 check in InflaterHuffmanTree.buildTree() is unnecessary (and causing this problem). I looked at the SharpZipLib version of this file (which is a port of this code to .NET) and they commented out the check (with a comment saying it is incompatible with dynamic trees and pkzip 2.04g). I've confirmed that removing the check fixes this bug and produces the correct output.
Created attachment 15786 [details] proposed fix
I can confirm that this patch fixes the issue both for the test file I submitted here and for the original file in which I noticed the problem.
I think I've found a zip file where this check was necessary to stop it causing problems. I'll see if I can find some data I'm allowed to attach here.
Created attachment 15832 [details] Sample file which is broken by the patch Attached file which caused problems when the lines were commented out.
It seems the problems are caused by the fact that the entry is encrypted yet Classpath's implementation ignores this and attempts to decompress it anyway. It seems there is a 2-byte "general purpose flags" value stored before the compression method, and if bit 0 is set the entry is encrypted. This could potentially be used to make getInputStream fail earlier to avoid that issue, in which case the existing patch for the large file itself can remain without causing a problem.
Created attachment 15833 [details] Detect encryption.patch Proposed fix to properly detect encrypted entries and reject getInputStream() before trying to do anything which won't work. Throws ZipException. Not sure if it should have been this or another kind of IOException.
*** Bug 41513 has been marked as a duplicate of this bug. ***
Created attachment 18682 [details] InflaterHuffmanTree.java.patch - better version Still perform the check but allow for a special condition where there is only one code.
Created attachment 18683 [details] Actually corrupt zip file Corrupt zip file sample I manually constructed to trigger the exception in the check.
I've confirmed the patch by Daniel Noll as correct and committed a variation of his patch (with a modified exception message).
Set to 0.99
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.