IZ70320: ZIPFILE.CLOSE() DOESN'T CLOSE INPUTSTREAMS OPENED WITH ZIPFILE.GETINPUTSTREAM().

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Error Message: Native OutOfMemoryError caused by exhaustion of
    virtual address space, particularly on Windows 32-bit.  Many
    small leaking allocations observed in the native C/C++ runtime
    heap, particularly 56-byte allocations.
    
    These allocations cause fragmentation of the native C/C++
    runtime heap.  The total amount of leaked memory is relatively
    small, but the amount of memory reserved for heap extensions is
    large (typified by large jumps in the amount of virtual address
    space in the memory map for the process).
    .
    Stack Trace: java/lang/OutOfMemoryError
    Stack trace varies.
    .
    The first pointer in leaking 56-byte allocation should point to
    an ANSI string representing a zip file entry name.  Many
    duplicates of the same entry names may be seen (these entry
    names may correspond to resources loaded using
    ClassLoader.getResourceAsStream(), particularly when the
    classloader is a WebSphere Application Server classloader).
    

Local fix

  • Ensure that your application calls ZipFileInputStream.close()
    explicitly.  This includes Middleware code.
    

Problem summary

  • ZipFile.close() does not close streams that have been opened
    using
    ZipFile.getInputStream(), as the JavaDoc describes it should.
    When the pattern of use for ZipFile is to:
    1. Open ZipFile
    2. Call ZipFile.getInputStream() without subsequently calling
    close() direcly on the
    InputStreams
    3. Call ZipFile.close()
    Then native memory associated with the returned InputStreams is
    not freed as it
    should be.  Note, the above pattern of use is perfectly valid
    according to the
    JavaDoc, and appears to be in use by some WebSphere Application
    Server's
    classloaders in response to ClassLoader.getResourceAsStream().
    

Problem conclusion

  • This defect will be fixed in:
    5.0.0 SR12
    .
    ZipFile.close() can now call close() on any InputStreams that
    have
    been opened using ZipFile.getInputStream(), but have not yet
    been closed explicitly
    by application.
    A new Java option is introduced to turn on this behaviour as
    there may be performance
    impact to add this support.
    Solution is either application closes the InpustStreams
    explicitly or run your Java
    applications with "-Dcom.ibm.zipfile.closeinputstreams=true".
    .
    To obtain the fix:
    Install build 20100402 or later
    

Temporary fix

Comments

APAR Information

  • APAR number

    IZ70320

  • Reported component name

    JAVA 5 CLASS LI

  • Reported component ID

    620500130

  • Reported release

    500

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-02-16

  • Closed date

    2010-04-23

  • Last modified date

    2010-04-26

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    JAVA 5 CLASS LI

  • Fixed component ID

    620500130

Applicable component levels

  • R500 PSN

       UP



Rate this page:

(0 users)Average rating

Document information


More support for:

Runtimes for Java Technology
Java Class Libraries

Software version:

5.0

Reference #:

IZ70320

Modified date:

2010-04-26

Translate my page

Machine Translation

Content navigation