AIX 调试工具
From developerWokrs
客户报告的 bug 不一定能够在开发环境中轻松地重现。应用程序崩溃、挂起和性能低下都可能无法重现。在这种情况下，需要可以在客户环境中使用的调试工具。本文讨论一种调试方法和一些常见的问题领域，以及 AIX 上可用的工具。注意，本文不讨论性能调试。
当环境中出现问题时，我们首先要查明操作系统版本和使用的硬件。这个步骤很重要，因为需要确认是否有可以进行调试的可重现环境，如果没有，就需要重新创建相同的环境。
通过运行 prtconf 命令查看总体系统配置。
清单 1. 总体系统配置
#prtconf System Model: IBM,8204-E8A Machine Serial Number: 06381D2 Processor Type: PowerPC_POWER6 Number Of Processors: 2 Processor Clock Speed: 4204 MHz CPU Type: 64-bit Kernel Type: 64-bit LPAR Info: 2 ibmmachine Memory Size: 9344 MB Good Memory Size: 9344 MB Platform Firmware level: Not Available Firmware Version: IBM,EL320_076 Console Login: enable Auto Restart: true Full Core: false |
以下命令显示 AIX 的版本、发布版和维护级别。
清单 2. AIX 的版本、发布版和维护级别
# instfix -i|grep AIX_ML
All filesets for 5.3.0.0_AIX_ML were found.
All filesets for 5300-01_AIX_ML were found.
All filesets for 5300-02_AIX_ML were found.
All filesets for 5300-03_AIX_ML were found.
All filesets for 5300-04_AIX_ML were found.
All filesets for 5300-05_AIX_ML were found.
All filesets for 5300-06_AIX_ML were found.
All filesets for 5300-07_AIX_ML were found.
# lslpp -h bos.rte
Fileset Level Action Status Date Time
----------------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte
5.3.0.50 COMMIT COMPLETE 10/17/07 16:34:57
5.3.0.60 COMMIT COMPLETE 03/11/08 16:08:59
5.3.7.0 COMMIT COMPLETE 03/12/08 11:28:55
# oslevel -r
5300-07
|
清单 3. CPU 和内核类型
# bootinfo -K 64 # bootinfo -y 64 |
清单 4. 已安装的软件产品
# lslpp -lc|grep -i perl /usr/lib/objrepos:perl.libext:2.1.0.10::COMMITTED:I:Perl Library Extensions : /usr/lib/objrepos:perl.rte:5.8.2.71::COMMITTED:F:Perl Version 5 Runtime Environment: |
#uptime 05:16PM up 2 days, 1:36, 4 users, load average: 1.95, 1.90, 1.80 |
如果一个程序终止了，根据终止类型，可能会生成核心文件（core file）。核心文件 是终止的进程的映像，即当进程崩溃时内存中所有数据的转储。当发生以下事件时会生成核心文件：
-
SIGQUIT— 退出 -
SIGILL— 无效的指令 -
SIGTRAP— 跟踪捕捉 -
SIGIOT— 结束进程 -
SIGEMT— EMT 指令 -
SIGFPE— 算术异常、整数被零除或浮点异常 -
SIGBUS— 规格异常 -
SIGSEGV— 分割违例 -
SIGSYS— 参数对于子例程无效
在应用程序崩溃时，不一定会生成核心文件，核心文件还可能不完整。在这种情况下，可能需要启用核心文件转储或增加核心文件大小。
#ulimit -c |
这个命令显示 shell 核心文件大小的当前值（软限制），这个值应用于从这个 shell 启动的所有进程。如果这个值是零，那么执行以下命令把它提高到最大值（硬限制 ）：#ulimit -c <val>。
#ulimit -Hc |
编辑 /etc/security/limits 文件，修改软和硬核心大小的 <value>：
core = <value> core_hard = <value> |
在 /etc/profile 中添加以下设置以设置软限制：
#ulimit -S -c <value> > /dev/null 2>&1 |
chuser attribute=value username |
可以设置的属性：
-
core— 软限制的大小 -
core_hard— 硬限制的大小 -
core_path— 核心文件目录路径启用/禁用 -
core_pathname— 生成核心文件的目录
使用 chcore 命令修改设置，使用 lscore 查看当前的核心设置。
chdev -l sys0 -a fullcore=true |
gencore 实用程序为指定的每个进程创建核心映像。然后可以通过 dbx 等调试器使用核心映像。
snapcore 命令收集核心文件、程序和程序使用的库，然后把它们压缩为一个 PAX 文件。可以把这个文件传输到调试环境中，使用它判断和解决应用程序的问题。
snapcore -r<core file name> <program name> |
PAX 文件在 /tmp/snapcore 目录中生成。
如果创建了核心文件，错误日志记录进程应该会记录一个错误日志项，这个进程常常在发生第一个软件故障时启动。
- 获取错误日志
清单 5. 获取错误日志
# errpt -a LABEL: CORE_DUMP IDENTIFIER: C69F5C9B Date/Time: Fri Nov 13 17:04:55 IST 2009 Sequence Number: 235168 Machine Id: 000381D2D900 Node Id: ibmmachine Class: S Type: PERM 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: 765972 FILE SYSTEM SERIAL NUMBER 8 INODE NUMBER 352516 CORE FILE NAME /opt/IBM/InformationServer/Server/Projects/sample1/core PROGRAM NAME dsapi_slavePROGRAM_NAME下面指出生成核心的程序。 - 显示错误和相应的时间
可以使用
errpt命令显示过去 24 小时内所有错误的详细报告：# date Fri Nov 13 18:18:33 IST 2009 # errpt -a -s 1112181809
清单 6. 创建核心的应用程序
#lquerypv -h core 500 64 The executable is located between the pipes on the right hand side of the output and in the case below, it is uvsh. 00000500 00000001 00000000 00000043 00000003 |...........C....| 00000510 F1000100 3361BFF8 00000000 00000000 |....3a..........| 00000520 00120000 75767368 00000000 00000000 |....uvsh........| 00000530 00000000 00000000 00000000 00000000 |................| 00000540 00000000 00000000 00000000 5A9E9590 |............Z...| 00000550 00000000 00000016 00000000 00000BF1 |................| 00000560 00000000 00000000 00000000 00001019 |................| |
对导致核心转储的二进制可执行文件运行 dbx。这会显示出问题的调用。
#dbx exe core |
列出 sys0
lsattr -El sys0 |
有用的属性：
-
autorestart— 在崩溃之后自动地重新引导系统 -
fullcore— 启用/禁用完整的核心转储 -
maxuproc— 每个用户允许的最大进程数量
chdev -l sys0 -a attribute=value |
在 AIX 上有许多用于检查应用程序错误、挂起和崩溃的工具。下面讨论其中几个工具。
可以使用以下工具检查进程或核心。所有命令都以 proc<cmd> 开头。在生产环境中检查进程时应该特别小心，因为这些工具在进行检查时实际上会停止进程。
-
procstack输出进程的堆栈跟踪。 -
procflags输出进程的未处理信号和持有的信号。 -
procsig输出进程的信号操作和处理程序。 -
procfiles报告每个进程中所有打开的文件的fstat和fcntl信息。 -
procwdx输出分别用于停止和重新运行进程的procstop和procrun的当前工作目录。 -
proctree输出包含指定进程 ID (PID) 或用户的进程树，子进程相对于父进程缩进显示。
truss 生成跟踪信息，包括进程执行的系统调用、它收到的信号和它导致的机器错误。在默认情况下，不跟踪用户级函数。可以使用truss -u '*' -p <pid> 启用对所有用户级函数的跟踪。
有用的选项：
-
-p提供 PID。 -
-u [!] [LibraryName [...]::[!]FunctionName [...] ]跟踪从用户库动态装载的用户级函数。 -
-a显示每个exec()系统调用中传递的参数字符串。 -
-f跟踪通过fork()或vfork()创建的所有子进程，跟踪输出中包括它们的信号、错误和系统调用。 -
-m [!]Fault跟踪进程中列出的机器错误（见 sys/procfs.h 头文件）。 -
-s [!] Signal允许列出要跟踪或排除的信号。
不允许使用 truss 跟踪通过 SUID 作为另一个用户运行的命令，因为系统认为它不属于您使用的用户。系统会显示以下错误：
# truss -deaf -o truss.out program truss: 0915-015 Cannot create subject process. wait4all: i: 0, status: 32512, pid: 643282, created: 0 |
要想使用 truss 跟踪这种命令，应该：
- 作为需要检查的用户登录，使用
ps命令查明 shell 的 PID。 - 作为 root 用户启动一个新会话，使用
truss跟踪这个 shell 会话。 - 这个新会话将记录原 shell 中的所有活动。运行失败的命令并停止
truss。可以通过查看 truss.out 文件检查错误。
在典型的数据库系统环境或执行大量文件处理的应用程序中，查明进程拥有的文件的名称对于调试问题可能很重要。
- 列出进程拥有的文件的名称：
procfiles -n <pid>
- 如果知道
inode号，那么：- 使用
ncheck根据inode号生成路径名ncheck - i <inode>
- 列出文件并使用
grep搜索inodels -ail |grep <inode>
- 使用
netstat -a |grep <process name> |
如果客户机进程状态字段长时间处于 FIN_WAIT 状态，或服务器进程状态字段长时间处于 CLOSE_WAIT，进程就是发生了挂起 或 死锁。
运行 netstat -Aan，其中的 -A 显示与套接字相关联的任何协议控制块的地址。
清单 7. 套接字到进程 ID 映射
#netstat -Ana|grep 31538 f10006000041c398 tcp4 0 0 *.31538 *.* LISTEN f10006000677d398 tcp4 0 0 9.122.87.107.31538 9.122.87.51.2500 ESTABLISHED f100060006affb98 tcp4 0 0 9.122.87.107.31538 9.122.87.51.2511 ESTABLISHED f1000600066d1398 tcp4 0 0 9.122.87.107.31538 9.122.87.51.2521 ESTABLISHED |
运行 kdb 并对感兴趣的套接字的地址执行 sockinfo。
清单 8. 运行
kdb
(0)> sockinfo f10006000677d398 tcpcb
---- TCPCB ----(@ F10006000677D398)----
seg_next......@F10006000677D398 seg_prev......@F10006000677D398
t_softerror... 00000000 t_state....... 00000004 (ESTABLISHED)
t_timer....... 00000000 (TCPT_REXMT)
....
proc/fd: fd: 4
SLOT NAME STATE PID PPID ADSPACE CL #THS
pvproc+01B000 108*dsapi_sl ACTIVE 006C0D0 00B206C 000000002E707590 0 0001
|
#ps -fp <pid> |
查看 time 字段。如果它长时间不变，那么很可能是发生了死锁或挂起。
#ps -mp <pid> -o THREAD |
LDR_CNTRL 环境变量控制进程可以使用的数据段数量。下面的示例定义一个额外的数据段：
export LDR_CNTRL=MAXDATA=0x10000000 start the process unset LDR_CNTRL |
这个值会显著影响 AIX 上一些与内存相关的问题。MAXDATA 控制 malloc 分配的内存量，使用 LDR_CNTRL=MAXDATA=0xN0000000 修改MAXDATA（其中的 N 等于数据段数量）。
在 32 位系统上，默认的地址空间模型是对于用户和堆栈数据使用单一数据段，最大总大小接近 256 MB。如果应用程序需要更多内存，可以通过设置 MAXDATA 使用较大或非常大的地址空间模型。
关于大程序支持的更多信息参见 AIX 文档。
还可以使用 ldedit 命令在可执行程序中修改 MAXDATA 设置。
ldedit -bmaxdata:0x80000000 sampleexec |
对于大地址空间模型下的 32 位程序，允许的最大值是 0x80000000；对于非常大的地址空间模型，是 0xD0000000。对于 64 位程序，可以指定任何值，但是数据区域不能超过 0x06FFFFFFFFFFFFF8。
ps 命令报告 malloc 分配的内存，但是不包含 mmap 分配的内存。svmon 报告完整的进程内存使用情况。
#svmon -P <pid> -m -r -i <interval> |
在默认情况下，内存和分页空间采用晚分配。PSALLOC 环境变量控制分配机制。
#export PSALLOC=early |
在默认情况下，当调用 malloc 时并不分配分页空间，而是到引用它时才分配。malloc 可能会过量分配内存，其他进程可能在当前进程之前获得资源，这会导致错误。把 PSALLOC 设置为 “early” 可以保证进程获得内存分配请求所请求的分页空间。
使用 #ipcs -mop 输出关于活跃共享内存段的信息。使用 ipcrm [ -m SharedMemoryID ] [ -M SharedMemoryKey ] 删除共享内存段。
本文讨论了可以在客户环境中帮助调试问题的一些工具。还讨论了一种调试方法和一些常见的问题领域，以及可用的 AIX 工具。