PQ62669: WHEN SMALL LE STACK SIZE USED, STORAGE OVERLAYS CAN SURFACE AS ABEND0C1, ABEND0C4 OR ABEND0C6 IN LE OR WEBSPHERE METHODS.

APAR status
Closed as duplicate of another APAR.

Error description
Because of the linkage used in WebSphere PL/X modules, when
a long calling sequence of methods causes LE to expand DSAs
into a second stack segment (STKU), the "end of stack" pointers
do not get reset properly, causing overlays of whatever storage
lies in between the STKUs.  The overlay occurs because of the
PL/X linkage, control does not returned to LE for LE to
properly reset the end of stack pointer in the CAA to the
end of the first STKU and remains pointing to the end of a
subsequent STKU even tho the calling sequence of DSAs has
unwound enough to fit back in the first STKU.  Thus LE then
thinks it owns all the storage in between the STKU segments
for stack frame storage.
.
This can occur when SMF recording for WebSphere is enabled
since much of the SMF code is written in PL/X.  However this
problem is not limited to having SMF recording enabled and can
be seen when the first DSA in a subsequent STKU is a PL/X
method.
.
These abends can occur during deployment or
installation of J2EE applications when using
the Administration Application (SM EUI SM/EUI).
They can also occur at other times.
.
This APAR is being created to address the problem in the
linkage of the PL/X modules.
.
To verify this condition is occurring, do the following steps:
.
1) Obtain an SVC dump at the time the overlay occurs.
.
2) Make note of the ASID and TCB taking the abend.
.
3) From the SVC dump, use the ip verbx ledata command with the
     ceedump option to obtain a traceback with the DSA address
     of the thread taking the exception/abend.  For example,
     ip verbx ledata 'ceedump asid(xxxx) tcb(xxxxxxxx)'
.
4) Make note the top DSA address prior to LE signal handling
     gaining control.
.
5) Issue ip verbx ledata 'summ asid(xxxx) tcb(xxxxxxxx)'
     Note the address for the end of stack pointer, "EOS:", in
     the CEECAA control block.
.
6) Issue ip verbx ledata 'stack asid(xxxx) tcb(xxxxxxxx)'
     Go to the bottom of this section.  If there is more than
     one STKU stack segment, this could be the problem and you
     need to continue with these steps.  If there is only one
     STKU, it is not this problem and you need to pursue a
     different cause of the abend.
.
7) In the list of STKU stack segments from #6, determine which
     one the DSA address from #4 falls in to (SEGMENT_LEN
     added to STKH address tells you this).  The STKUs are
     chained together so the first in the list is the first
     stack segment containing the earliest DSAs.  The next
     STKU in the list is the next block of DSAs, etc.
.
     An example of this problem
     DSA address is 2699A790 and the STKU list looks like:
.
     User Stack Control Blocks
.
       STKH:  2698BFC8
     +000000  EYE_CATCHER:STKU  NEXT:3E1FA000     PREV:2698B70C
     +00000C  SEGMENT_LEN:00010000
.
       STKH:  3E1FA000
     +000000  EYE_CATCHER:STKU  NEXT:2698B70C     PREV:2698BFC8
     +00000C  SEGMENT_LEN:00010000
.
     And the CEECAA EOS pointer is 3E20A000 (3E1FA000 plus
     00010000 (SEGMENT_LEN)).
.
     If the DSA address falls beyond the end of one of the
     STKUs, that is confirmation of this problem.  If the DSA
     is in the first STKU but the EOS pointer from #5 points to
     the end of the second STKU, that is confirmation of this
     problem.  If there are more than 2 STKUs, an EOS pointer
     pointing to the end of a subsequent STKU where the DSA is
     in an earlier STKU, it is confirmation this is the
     problem.  If the EOS pointer points to the end of the STKU
     that also contains the DSA pointer (i.e. EOS pointer was
     reset correctly), the this is not a match for the problem
     and you need to pursue another cause of the abend.
Local fix
Set LE STACK to 128K or higher (depending on how long the
calling sequence is, 128K may not be enough).  The STACK
runtime option can be passed in as an LE runtime option before
the "/" in the PARM= part of the WebSphere procs, such as:
PARM='STACK(128K,128K,ANY)/ -ORBsrvname &SRVNAME &PARMS'
.
It can also be changed via traditional methods of changing
LE runtime options.
Problem summary Problem conclusion Temporary fix Comments
The solution to the issues reported by APAR PQ62669 have been
provided in APAR 
PQ66463.
APAR information
APAR number PQ62669
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 401
Status CLOSED DUB
PE NoPE
HIPER NoHIPER
Submitted date 2002-06-26
Closed date 2002-09-30
Last modified date 2002-09-30

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Fix information

Applicable component levels


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 401
Software edition:
Reference #: PQ62669
IBM Group: Software Group
Modified date: Sep 30, 2002