United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4615343 : ZipFile.entries() throws java.lang.InternalError

Details
Type:
Bug
Submit Date:
2001-12-18
Status:
Resolved
Updated Date:
2006-08-05
Project Name:
JDK
Resolved Date:
2006-08-05
Component:
core-libs
OS:
linux,windows_98,windows_nt,windows_2000,windows_xp
Sub-Component:
java.util.jar
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
8.0pe,1.4.0,1.4.1,1.4.2,1.4.2_02,5.0
Fixed Versions:

Related Reports
Relates:

Sub Tasks

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

                                    

Comments
EVALUATION

Instead of throwing an InternalError, the zip file implementation
now throws java.util.zip.ZipError.

The new exception is controversial and extends InternalError.  In
general, this not recommended pratice but was needed for compatibility.
Existing programs may have worked around this problem by catching
InternalError.  Such programs will continue to work but we recommend
that all clients are updated to catch java.util.zip.ZipError instead.
                                     
2006-10-03
WORK AROUND



Name: nt126004			Date: 12/18/2001


Customer Workaround :
catch InternalError when enumerating zip entries.
======================================================================
                                     
2004-10-13
EVALUATION

The submitter's reasoning is persuasive.  

It is too late to fix this for Tiger.

An audit of all the logic in zip_util.c, looking for unwarranted
assumptions on the correctness of the zip file, is a good idea.
###@###.### 2004-01-11
                                     
2004-01-11



Hardware and Software, Engineered to Work Together