After patching AIX to 7.1TL4SP3 or 7.2TL1, several programs, including the Veritas Cluster Server agent HostMonitor and VxFS mount, behave abnormally or dump core
Article ID: 100033742
Updated On:
Description
Error Message
The HostMonitor agent generates a core dump. Here is evidence of a core dump found in AIX's errpt output:
LABEL: CORE_DUMP
IDENTIFIER: A1234567
Date/Time: Thu Jan 12 02:44:08 2017
Sequence Number: 33420
Machine Id: 0012345678
Node Id: server101
Class: S
Type: PERM
WPAR: Global
Resource Name: SYSPROC
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Probable Causes
SOFTWARE PROGRAM
User Causes
USER GENERATED SIGNAL
Recommended Actions
CORRECT THEN RETRY
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
RERUN THE APPLICATION PROGRAM
IF PROBLEM PERSISTS THEN DO THE FOLLOWING
CONTACT APPROPRIATE SERVICE REPRESENTATIVE
Detail Data
SIGNAL NUMBER
11
USER'S PROCESS ID:
10158238
FILE SYSTEM SERIAL NUMBER
1
INODE NUMBER
2
CORE FILE NAME
//core
PROGRAM NAME
HostMonitor
VxFS mount failed to mount a file system because the program memory (program variables) were corrupted.
# /sbin/helpers/vxfs/mount -V vxfs /dev/vx/dsk/asextrcobratdgapp/lvpatrol /patrol
UX:vxfs mount: ERROR: V-3-20002: Cannot access re/lib/zoneinfo/posixrules: A file or directory in the path name does not exist.
UX:vxfs mount: ERROR: V-3-24996: Unable to get disk layout version
The device path variable "/dev/vx/dsk/asextrcobratdgapp/lvpatrol" was corrupted to "re/lib/zoneinfo/posixrules".
Cause
IBM states that there is an issue with the initialization of the Olson time zone format, such as TZ=America/New_York, which results in too much stack space given to threads. This issue was introduced with AIX 7.1TL4SP3 and 7.2TL1.
http://www-01.ibm.com/support/docview.wss?uid=isg1IV92499
IV92499: CORE DUMPS IN MULTITHREADED PROCESS USING OLSON TZ
An example stack from the HostMonitor agent core dump follows:
# dbx /opt/VRTSvcs/bin/HostMonitor /tmp/core
Type 'help' for help.
[using memory image in /tmp/core]
reading symbolic information ...
Segmentation fault in _rec_mutex_lock at 0xd01139fc ($t2)
0xd01139fc (_rec_mutex_lock+0x5c) 801f0000 lwz r0,0x0(r31)
(dbx)
This is a segmentation fault in the _rec_mutex_lock routine, which is in AIX code.
Resolution
IBM has introduced APAR IV92499 to deal with the problem. Refer to IBM Support for further details.
Issue/Introduction
