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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.