JDK-8044727 : Problem reading the contents of some zip files
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 8u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2014-05-30
  • Updated: 2016-06-13
  • Resolved: 2014-06-04
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.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20Fixed 9 b17Fixed
Description
FULL PRODUCT VERSION :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Mac OS 10.9.3

A DESCRIPTION OF THE PROBLEM :
On some zip files this error is thrown when reading:

Exception in thread "main" java.util.zip.ZipException: invalid entry size (expected 0 but got 355764 bytes)


REGRESSION.  Last worked in version 7u55

ADDITIONAL REGRESSION INFORMATION: 
So far any jdk8 version tested.

java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Standard code to read Zip files.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No error should occur.
ACTUAL -
An exception is thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
$ java ZipReader simple.zip 
Entry: QuickLook/Thumbnail.jpg len 4254 added 05/03/13
Entry: QuickLook/Preview.pdf len 8102 added 05/03/13
Entry: buildVersionHistory.plist len 355 added 05/03/13
Entry: index.xml len 0 added 05/03/13
Exception in thread "main" java.util.zip.ZipException: invalid entry size (expected 0 but got 355764 bytes)
	at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:383)
	at java.util.zip.ZipInputStream.read(ZipInputStream.java:196)
	at java.io.FilterInputStream.read(FilterInputStream.java:107)
	at ZipReader.main(ZipReader.java:47)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.util.Date;
import java.util.zip.ZipEntry;
import java.util.zip.ZipInputStream;

public class ZipReader
{
    // Parse the supplied .zip file
    public static void main(String args[]) throws Exception {
        if (args.length != 1) {
            System.err.println("zipreader zipfile");
            return;
        }

        byte[] buffer = new byte[2048];

        // open the zip file stream
        InputStream theFile = new FileInputStream(args[0]);
        ZipInputStream stream = new ZipInputStream(theFile);

        try {
            // Just iterate through each zip file entry
            ZipEntry entry;
            while((entry = stream.getNextEntry()) != null) {
                String s = String.format("Entry: %s len %d added %TD",
                                entry.getName(), entry.getSize(),
                                new Date(entry.getTime()));
                System.out.println(s);

                int len = 0;
                while ((len = stream.read(buffer)) > 0) {
                    // NOTHING
                }
            }
        } finally {
            stream.close();
        }
    }
}

// There does not appear to be any option I can see here to upload a sample zip that causes the problem.

---------- END SOURCE ----------


Comments
According to Xueming: "Regression caused by the change for JDK-6303183", which was introduced for JDK 8. Due to this, label escape-old was added.
07-04-2015

Regression caused by the change for 6303183, in which the new code tries to interpret the ZIP64 extra field without checking if necessary (the original impl only does this when the size/csize is the zip64 magic numbers). The "offending" simple.zip has an extra field for index.xml that has a "zip64 tag" but with 0-filled data...
04-06-2014

sample.zip file obtained from submitter. (attached to bug report) I've verified that it passes in JDK 7 and fails for JDK 8. Further comments from submitter : FYI, we have a number of .zip format files that currently fail our test suite under jdk8 - all of the failing files are from the older versions of Mac OS Pages or Numbers - All other zip tools seems to handle the files correctly, so I believe they are valid and here the jdk8 is at fault (test suite has worked since jdk6).
03-06-2014

submitter contacted for sample zip file.
03-06-2014