Name: nt126004 Date: 12/18/2001


java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

A bad ZipEntry is not reported when the ZipFile is constructed.

ZipFile does not throw this error in its constructor so when the entries()
method is called it throws a java.lang.InternalError("jzentry == 0")

java.lang.InternalError should be reserved to indicate an internal error in the
java virtual machine.

The expected behaviour is that when constructing the corrupt zip file a
ZipException is thrown.

Here is the error I received:

Caught: java.lang.InternalError: jzentry == 0,
jzfile = 9825168,
total = 10,
name = c:\temp\0037c4b0-000000ea81fa8b82.zip,
i = 1,
message = invalid LOC header (bad signature)
(Review ID: 136967)
======================================================================

Name: nt126004 Date: 05/20/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :
at least other Windows versions.

A DESCRIPTION OF THE PROBLEM :
The following exception is thrown on enumerating a broken zip
file:
java.lang.InternalError: jzentry == 0
at
java.util.zip.ZipFile$2.nextElement(Unknown Source)
With JRE
1.4:
java.lang.InternalError: jzentry == 0,
 jzfile = 1190293256,
 total = 38,
 name = F:\Temp\db\inserted_2bytes.zip,
 
i = 1,
 message = invalid LOC header (bad signature)
at
java.util.zip.ZipFile$2.nextElement(ZipFile.java:303)

The
broken zip file can be created by inserting two extra bytes into the middle
of the zip file. If it's a problem to create one, I can mail it.

The problem is
evidently in the ZipFile$2 class (Enumeration): instead of throwing an
InternalError, ZipException should be thrown. Or "getNextEntry(long
jzfile, int i)" method should never return 0, throwing ZipException on
its own.

This problem is also described in BugId 4353705 and 4615343
(marked as ease-of-use enhancement for some reason), but 4353705 was
closed as fixed because other problem was fixed - zip cache could contain
stale data. Evaluation recommends to submit another bug if the problem is
still observed: "If you are using Merlin RC1 or later, and still encounter
this, please file
a new bug with steps we can easily reproduce.". It's
still observed with JRE 1.3.1_03 and 1.4.0. Thus, submitting a new bug.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. open zip file using ZipFile constructor
2. call ZipFile.entries()
method and enumerate all the entries

EXPECTED VERSUS ACTUAL BEHAVIOR :
An expected exception like ZipException should be thrown since the
situation is perfectly valid - external data are invalid. InternalError
propagates to the top of the stack uncaught, causing the app function to
silently crash (in GUI app) or even a thread to stop.

This bug can be reproduced always.

CUSTOMER WORKAROUND :
Catch InternalError or test the zip file validity before creating
ZipFile instance.
(Review ID: 146723)
======================================================================