IT19194: Core file from SIGSEGV in zswLock under MQCONNX

APAR status

• Closed as program error.

Error description

• After upgrading from MQ V8 to V9.0.0.0 a 32-bit application
  program that had been working without trouble is now
  consistently reporting SIGSEGV in zswLock upon its first MQCONNX
  attempt. No MQ FDCs reported.
  
  The application had one or both of:
  - relatively small thread stack size
  - relatively high use of thread stack before calling MQCONNX
  
  (dbx) where
  zswLock() at 0xd210a8cc
  zswCheckAndInit() at 0xd21b0154
  zswGetEntryPointsByName() at 0xd21b5eac
  zswMQCONNX_Client_Call() at 0xd21e1540
  MQCONNX() at 0xd1ae0f4c
  

Local fix

• There are two workarounds to this problem:
  
  1. Tell the system to use bigger thread stack by tuning the
  thread support tuneable parameter AIXTHREAD_STK  as seen in
  example 15 in the AIX 6.1 Knowledge Center.  Example:
  export AIXTHREAD_STK=130000
  
  2. Build the application as a 64 bit application using -q64
  compile read stacks should be available by default in this case.
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users running 32-bit MQ application programs or any MQ
  application program with one or both of:
  - relatively small thread stack size
  - relatively high use of thread stack before calling MQCONNX
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  Stack space required by the zswLock() function has grown by
  approximately 45 KB in MQ 9.0.0.0 compared to previous releases.
   When MQCONNX processing called this function, this caused the
  thread stack usage to grow close to its configured limit within
  the application process where the MQ code was running.  The
  SIGSEGV memory exception occurred while zswLock() was increasing
  the stack further as it was preparing to make a call to another
  routine.
  
  It is possible to respond to this situation by configuring the
  system to allocate bigger thread stack space for the application
  process (for example by using the AIXTHREAD_STK environment
  variable on AIX).  However, this 45 KB memory block need not be
  allocated from the stack, and instead can easily be allocated
  from the process heap instead, so a change to IBM MQ product
  code is preferable, to avoid the issue occurring.
  

Problem conclusion

• IBM MQ has been changed to allocate the 45 KB memory from
  process heap instead of from the thread's stack space.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v9.0 CD    9.0.3
  v9.0 LTS   9.0.0.2
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

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

  IBM MQ BASE M/P

• Fixed component ID

  5724H7261

Applicable component levels

• R900 PSY

     UP