United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5105410 : ZipFile$ZipFileInputStream doesn't close handle to zipfile

Details
Type:
Bug
Submit Date:
2004-09-22
Status:
Resolved
Updated Date:
2004-11-19
Project Name:
JDK
Resolved Date:
2004-11-19
Component:
core-libs
OS:
solaris_10,windows_xp,windows_2000
Sub-Component:
java.net
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.3.1_13,1.4.2_07,6u10
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
The bug seems to be located in the inner class in java.util.zip.ZipFile ? ZipFileInputStream, and more specifically its

public void close()

It doesn?t close its field handle to the ZipFile there and this leaves the file handle leak.

In the customer case the usage of URL.openStream() the customer cannot get access to the zipFile handle and there is no way it can be explicitly closed.

The problem resulting of this effect is that the partner's J2EE is not able to redeploy applications
###@###.### 10/30/04 01:46 GMT

                                    

Comments
EVALUATION

This sounds like it's the same problem as described in 

5072161: OutOfMemoryError while using GZIPOutputStream, zlib memleak
5092131: using 1 MB pagesize throws "not enough space" error with 32bit JVM

the submitter has not provided enough information to determine whether it's
the same problem.  The description in those bugs may enable the submitter
to find a good workaround.

We need a small program demonstrating the problem.

The suggested fix looks incorrect.  If two inputstreams are opened to
read from two different entries in the same zipfile, then the zip file
should not be closed when one of the inputstreams is closed.

Looks like Not Our Bug.

###@###.### 2004-09-24

###@###.### writes:
"At first sight, it looks like it might be a problem
with JarURLConnection. The problem is that JarURLConnection
opens a JarFile object and then returns an InputStream
acquired from the JarFile. Closing this stream cannot
close the enclosing JarFile because the JarFile does not
know if more entries will be requested from it.

I think JarURLConnection should wrap its own stream type
around the inputstream acquired from the jarfile, and this
object can take care of closing the jarfile. This should
be straightforward because one JarURLConnection can only be
used to access one Jar entry.

Then you would not depend on closing the jarfile explicitly
from the app, or on the finalizer being called.
This is a pretty sensitive area so we would need to check this
out thoroughly to make sure it's right."

I (Martin) agree with this assessment, although I have not
thoroughly investigated it.  I don't think there's anything
that code in java.util.{jar,zip} can do to fix it.
Reassigning this bug to classes_net.
###@###.### 10/30/04 01:46 GMT
                                     
4-10-30 00:00:00
SUGGESTED FIX

You can start Kaloyan?s test with this line :

java -Xbootclasspath/p:fix.zip FileTest

and put the fix.zip(it contains a fixed version of the inner class) in the working dir.  
The customer provided already a suggestion to fix the problem.
See fix.zip in the attachment.
 
You can start the test with this line :

java -Xbootclasspath/p:fix.zip FileTest

and put the fix.zip(it contains a fixed version of the inner class) in the working dir.  
You can see the changed lines in  close() and close1() in the ZipFileInputStream.

Close1() is privately used from the other methods of ZipFile, while close() is left only for explicit calls.
                                     
2004-09-30



Hardware and Software, Engineered to Work Together