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

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 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