PM07699: ZIPFILE.CLOSE() DOESN'T CLOSE INPUTSTREAMS OPENED WITH ZIPFILE.GETINPUTSTREAM(), FIX FOR APAR PM02116

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

  • I'm not aware of a simple workaround without changing
    application or
    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:
    1.4.2  SR 13 FP8
    .
    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 application with
    "-Dcom.ibm.zipfile.closeinputstreams=true".
    .
    To obtain the fix:
    Install build 20100825 or later
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM07699

  • Reported component name

    JAVA(1.3/1.4 CO

  • Reported component ID

    5648C9800

  • Reported release

    42A

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-02-16

  • Closed date

    2010-09-30

  • Last modified date

    2011-01-05

  • 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(1.3/1.4 CO

  • Fixed component ID

    5648C9800

Applicable component levels

  • R42A PSY

       UP



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

1.4.2

Reference #:

PM07699

Modified date:

2011-01-05

Translate my page

Machine Translation

Content navigation