PM53411: STORAGE LEAK OF NATIVE STORAGE IN SUBPOOL 132 KEY 2 IN A WEBSPHERE FOR Z/OS APPLICATION CONTROL REGION

APAR status

• Closed as fixed if next.

Error description

• he storage leaked are the native C++ objects related to a
  CORBA::Request (bbooobj.cpp).  This native Request object points
  to a ORB_Request object (bbooorbr.cpp).   The ORB_Request object
  owns storage from the ORBR Cellpool and an IOR Object.   The
  CORBA::Request, ORB_Request object (and object data -- which
  includes the Cellpool buffer from subpool 132 key 2), and the
  IOR Object are leaked per Marshalling error in the
  _xxxxStub.java invoke method.
  
  The error without the IDL generated _xxxxxStub code caused the
  cleanup of the above mentioned native objects to be skipped.
  
  Here's some storage references.  First, the storage leaked from
  subpool 132 key 2 is the storage related to the SMD Buffers
  taken from the ORBR Cellpool.  Here's an example of a cell from
  an expanded ORBR small cellpool:
  
  C3E2D9C3   D7C5C201   D6D9C2D9   6DE2D4D3   | CSRCPEB.ORBR_SML |
  77B0C000   00000090   00000268   764C0000   | ..{..........<.. |
  00000000   04000000   77B0C090   77B88090   | ..........{..... |
  0007D000   0000007D   00000010   00000000   | ..}....'........ |
  LENGTH(X'30')--All bytes contain X'00'
  
  
  In the above storage reference at offset x'1C' is the expansion
  instance for this current extent.  So, from above, instance of
  x'00000268' indicates that this is the x'268' extent of this
  cellpool.  The following word is the pointer to the next extent
  (so it expanded at least 1 more time in this example).
  
  The cells from the above storage will contain ORBR SMD data and
  an example of them is as follows:
  
  00000000   D6D9C2D9   00000100   00000000   | ....ORBR........ |
  00010649   09B70000   0000A000   00010200   | ................ |
  LENGTH(X'10')--All bytes contain X'00'
  00000000   00000000   7C79A9D8   00000428   | ........@`zQ.... |
  00000051   0000006F   009BB250   00000000   | .......?...&.... |
  00000000   00000000   00000000   FFFFFFFF   | ................ |
  00000000   00000000   00000004   0000001C   | ................ |
  00000000   00000000   00000001   00000000   | ................ |
  FFFFFFFF   00000001   00000000   00000000   | ................ |
  LENGTH(X'30')--All bytes contain X'00'
  00000002   02000000   00000000   00000000   | ................ |
  00000000   00000000   00000001   026A0007   | ................ |
  00000000   00000001   06390010   00000000   | ................ |
  LENGTH(X'50')--All bytes contain X'00'
  00000000   80000000   00010271   027C0000   | .............@.. |
  LENGTH(X'A0')--All bytes contain X'00'
  00000000   80000000   000104ED   014C0000   | .............<.. |
  LENGTH(X'60')--All bytes contain X'00'
  00000000   C6D9C5C5   4000A497   8481A385   | ....FREE .update |
  00000002   78000000   00000000   31C9C4D3   | .............IDL |
  7A839694   4B898294   4BA6A24B   8393A4A2   | :com.ibm.ws.clus |
  A3859961   979996A7   A861C393   A4A2A385   | ter/proxy/Cluste |
  99C38193   93828183   927AF14B   F0000000   | rCallback:1.0... |
  ...
  00000000   00E3E8D7   C5C9C4D3   7A839694   | .....TYPEIDL:com |
  4B898294   4BA6A24B   8393A4A2   A3859961   | .ibm.ws.cluster/ |
  979996A7   A861C393   A4A2A385   99C38193   | proxy/ClusterCal |
  93828183   927AF14B   F0000000   00C3D3C1   | lback:1.0....CLA |
  E2839694   4B898294   4BA6A24B   8393A4A2   | Scom.ibm.ws.clus |
  A385994B   A996A24B   E2D9C485   A2839989   | ter.zos.SRDescri |
  97A38996   95D48195   81878599   C3819393   | ptionManagerCall |
  82818392   00E2E3D2   D5C8B6B5   C6F934E5   | back.STKNH..F9.V |
  AB000004   68000000   3A000000   0C003830   | ................ |
  48000100   01000101   00000000   00000000   | ................ |
  LENGTH(X'09B0')--All bytes contain X'00'
  
  The following IPCS command will format the ORB_Request info
  given a pointer to the SMD cell.   ip verbx bbordata 'asid(10a)
  objtype(0400AFFF) objaddr(007B0090)'.  Check the formatted
  results for the following set of data to help identify that this
  Request was "created" but not "invoked" (meaning that most
  likely a exception was thrown within the _xxxxStub code):
  
  -This first value indicates that this request was never queued
  to WLM for a Servant:
  0028  regReqID. 00000000
  
  -The following indicates that the comm_xxx routine was a locate
  request that returned immediately "here":
  ...  MthdRC... 00000004  MthRsCd.. 0000001C
  
  -The following indicates that no request body is present.   If
  the target IDL method takes parms, then this means they didn't
  make it into the request.  This is a strong indicator for a
  match to this problem:
  request_body:
  +01D8  bgAtrPtr. 00000000  bufNum... 0000      bufOff... 0000
  bgAlocTL. 00000000  attrLen.. 0000      bgAtrLen. 00000000
  
  
  The other Objects that are leaks have eyecatchers:
  "BBOORBR" for the ORB_Request object
  -Pointed to by the "ReqObjP.. 7C79A9D8" value from the IPCS
  command mentioned earlier.
  
  "BBO_CIOR" for the IOR Object
  -Pointed to by the ORB_Request Object (attribute
  m_targetObjectIORMap),
  
  Another must have to be this problem is that the target object
  had to be an IDL object.  The "TYPEIDL:com" in the target object
  key from the formatted ORB_Request would indicate an IDL object.
  
  KEYWORDS: abend878 abends878 878 s878 Ec3 0406002C sp132 k2 CR
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server V6.1.0                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Storage leak in WebSphere Application   *
  *                      Server for z/OS Control Region.         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A NullPointerException (NPE) thrown from an IDL generated _Stub
  causes native Request Objects and related storage to be leaked.
  The NPE results from passing a NULL byte[] as a parameter.  The
  marshalling is after the Request object and its native
  components have been initialized but before invocation of
  the target method.  The cleanup of the native Request objects
  are skipped in this window.
  APAR PM53411 is being closed FIN with concurrence from the
  submitting customer. This means that a fix to this APAR is
  expected to be delivered from IBM in a release which is being
  developed at the time that the APAR was closed. The latest
  release of the product to exit development at the time this
  APAR was closed was:
  WebSphere Application Server V8.0
  

Problem conclusion

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

Applicable component levels

• R610 PSY

     UP