AIX 调试工具

From developerWokrs

 

简介

客户报告的 bug 不一定能够在开发环境中轻松地重现。应用程序崩溃、挂起和性能低下都可能无法重现。在这种情况下，需要可以在客户环境中使用的调试工具。本文讨论一种调试方法和一些常见的问题领域，以及 AIX 上可用的工具。注意，本文不讨论性能调试。

 

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

CPU 和内核类型

清单 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 目录中生成。

查明创建核心文件的位置和生成它的程序

如果创建了核心文件，错误日志记录进程应该会记录一个错误日志项，这个进程常常在发生第一个软件故障时启动。

1. 获取错误日志 
   
   清单 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_slave
   

   
   

   PROGRAM_NAME 下面指出生成核心的程序。

2. 显示错误和相应的时间

   可以使用 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 跟踪通过 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 文件检查错误。

查明进程打开的文件的名称

在典型的数据库系统环境或执行大量文件处理的应用程序中，查明进程拥有的文件的名称对于调试问题可能很重要。

1. 列出进程拥有的文件的名称：

   procfiles -n <pid>
   

   
   
2. 如果知道 inode 号，那么：
   • 使用 ncheck 根据 inode 号生成路径名

        
     	ncheck - i <inode>
     

     
     
   • 列出文件并使用 grep 搜索 inode

     	ls -ail |grep <inode>

     
     

连接或接受 TCP 连接时的进程挂起

netstat -a |grep <process name>

如果客户机进程状态字段长时间处于 FIN_WAIT 状态，或服务器进程状态字段长时间处于 CLOSE_WAIT，进程就是发生了挂起 或 死锁。

套接字到进程 ID 映射

运行 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

根据 CPU 使用量检查挂起

#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 工具。