当前位置：文档之家› AIX+下的+core+dump+分析

AIX+下的+core+dump+分析

本文简要介绍了AIX 平台下core dump 产生的原理以及相关定位方法。

Core dump 基本知识

本节主要探讨core dump 产生的背景知识。对这部分不感兴趣的读者可以直接阅读第二章，了解基本的core dump 定位手段。

起源

软件是人思维的产物。智者千虑，必有一失，人的思维总有缺陷，反映到软件层面上就是程序bug。程序bug 的终极体现就是core dump，core dump 是软件错误无法恢复的产物。

生成过程

进程core dump 与系统dump 的产生，从程序原理上来说是基本一致的。dump 的生成一般是在系统进行中断处理时进行的，下面简单介绍一下中断机制。

操作系统的中断机制

操作系统是由中断驱动的。广义的中断一般分为两类，中断(Interrupts) 和异常(Exceptions)。中断可在任何时候发生，与CPU 正在执行什么指令无关，中断主要由I/O 设备、处理器时钟（分时系统依赖时钟中断划分时间片）或定时器等硬件引发，可以被允许或取消。而异常是由于CPU 执行了某些指令引起的，可以包括存储器存取违规、除0 或者特定调试指令等，内核也将系统服务视为异常。系统对这两类中断的处理基本上是相同的。

每个中断都会唯一对应到一个中断处理程序，在该中断触发时，相应的处理程序就会被执行。例如应用进程进行系统调用时，就会触发一个软件异常，进入中断处理函数，完成从用户态到系统态的迁移并进入相应系统调用的入口点。应用进程coredump 也是一个类似的过程。

应用进程core dump 生成过程

在进程运行出现异常行为时，例如无效地址访问、浮点异常、指令异常等，将导致系统转入内核态进行异常处理（即中断处理），向相应的进程发出特定信号例如SIGSEGV、SIGFPE、SIGILL 等。如果应用进程注册了相应信号的处理函数（例如可通过sigaction 注册信号处理函数），则调用相应处理函数进行处理（应用程序可以选择记录信息后生成core dump 并退出）；否则将采取默认动作，例如SIGSEGV 的默认动作是生成core dump 并退出程序。

进程coredump 的时候，操作系统会将进程终止并释放其占用的资源，正常情况下，应用进程coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程，则这些进程会受到影响，至于后果则视其对此异常的具体处理而定。

由于相关指令已经包含在可执行文件中，core 文件一般只包含进程异常时相关的内存信息。其格式可参考/usr/include/sys/core.h 或者AIX 帮助文档的“Files Reference”章节。我们一般需要结合core 文件以及可执行程序，来分析问题所在。

注：由于进程信号处理本质上是异步的，应用进程注册的信号处理函数中使用的例程需要保证是异步信号安全的，例如不能使用诸如pthread_ 开头的例程。

系统dump 生成过程

系统异常dump 的具体过程与应用进程类似，但由于更接近底层，为了避免问题所在的资源（例如文件系统）正好包含在生成dump 需要使用的资源中，造成dump 无法生成，操作系统一般会用最简单的方式来生成dump。例如系统内存小于4G 的情况下，一般直接将dump 生成在pagingspace 中；大于4G 时，会建专门的lg_dumplv 逻辑卷（裸设备）保存dump 信息。在系统重启的时候，如果设置的DUMP 转存目录（文件系统中的目录）有足够空间，它将会转存成一个文件系统文件，缺省情况下，是/var/adm/ras/ 下的vmcore* 这样的文件。

系统dump 一般可以通过升级微码、提高系统补丁级别、升级驱动等方式解决。

应用进程core dump 分析

上一章我们介绍了core dump 产生的基本原理。本章我们将针对AIX 操作系统，介绍core dump 定位相关的背景知识。

环境变量设置

可以通过/etc/security/limits 文件对各用户的基本配置参数包括core 大小进行限制。或者通过ulimit 更改当前环境下的core 大小限制。

默认情况下，应用进程生成core dump 时都使用文件名core。为了避免同一工作目录下的进程core 相互覆盖，可以定义环境变量CORE_NAMING=true，然后启动进程，这样将生成名为

core.pid.ddhhmmss 的文件。可以使用file core 命令查看core 是哪个进程产生的。

默认情况下，应用进程dump 时会包含所有的共享内存，如果dump 时想排除共享内存内容，可以在启动进程之前设置环境变量CORE_NOSHM=true.

系统有一个参数fullcore 用于控制是否在程序coredump 时生成完整的core。为避免信息丢失，建议打开fullcore。可以使用lsattr –El sys0 查询是否将fullcore 打开，使用chdev -l sys0 -a fullcore=true 将fullcore 状态更改为打开。也可以在程序内部调用sigaction 例程设置fullcore，参考如下测试程序：

fullcore 设置示例

//test.C

#include

int main(int argc, char* argv[])

{

char str[10];

struct sigaction s;

s.sa_handler = SIG_DFL;

s.sa_mask.losigs = 0;

s.sa_mask.hisigs = 0;

s.sa_flags = SA_FULLDUMP;

sigaction(SIGSEGV,&s,(struct sigaction

*) NULL);

std::cout << " input str!\n" << std::endl;

std::cin >> str;

return 0;

}

寻找core dump

应用进程的core 产生在其当前工作目录下，可以在应用程序内部使用chdir 函数切换当前工作目录。使用procwdx 命令可以查看进程的当前工作目录。系统的core 生成在lg_dumplv 下，并在重启时转移到/var/adm/ras/ 目录下（如果有足够空间的话，否则继续保留在lg_dumplv，并随时有可能被覆盖）。可以使用errpt -a 查看标识C0AA5338 SYSDUMP（系统core）、B6048838 CORE_DUMP（进程core）的详细错误信息，获取生成core 的进程以及core 文件位置。使用snap –ac 收集系统的dump 信息。

core dump 信息收集

如果可能, 直接在发生coredump 的机器上用dbx 分析出结果, 这样是最方便的分析方法 . 这种情况下注意不要直接以root 用户登录然后用dbx 分析, 而必须在应用程序所属的用户下进行此操作,

因为core 可能需要依赖应用程序运行时对应环境下的某些库, 这样就要借助应用程序的环境变量 .

如果需取回生产机上的core 信息在实验室分析, 则需要搜集一些相关信息 . 进程core 分析一般至少需要依赖应用可执行程序，有时还需要包括一些运行时动态库信息。如果需要收集core 相关的完整信息，可运行snapcore < 可执行文件以及名称>，例如snapcore ./core ./a.out，然后在/tmp/snapcore 下取下相应的 .pax.Z 文件。

正常的收集过程应该如下:

snap core 收集过程

# snapcore ./core ./a.out

Core file "./core" created by "a.out"

pass1() in progress ....

Calculating space required .

Total space required is 14130 kbytes ..

Checking for available space ...

Available space is 807572 kbytes

pass1 complete.

pass2() in progress ....

Collecting fileset information .

Collecting error report of CORE_DUMP

errors ..

Creating readme file ..

Creating archive file ...

Compressing archive file ....

pass2 completed.

Snapcore completed successfully. Archive

created in /tmp/snapcore.

# cd /tmp/snapcore

# ls

snapcore_352276.pax.Z

# uncompress snapcore_352276.pax.Z

# ls

snapcore_352276.pax

# pax -r -f snapcore_352276.pax

# ls 注意需要保证有类似如下文件 ( 可执行文件，

/core/errpt/lslpp/usr 目录等 ):

README errpt.out usr

a.out lslpp.out

core snapcore_352276.pax

使用dbx 分析core dump 的例子

dbx 是AIX 下基于命令行界面的源码级调试工具。本文档只提供一些基本的dbx 分析指令，详细内容请参考“General Programming Concepts: Writing and Debugging Programs”关于dbx 的描述。

初步分析

示例：

显示出core 发生时，当前进程执行到的位置（-g 编译的情况下能够看到具体的行）：

注意：

如果分析的是异地core 文件，需要采用snapcore 收集相关core 信息。对于依赖链接库的情况，注意需要增加-p oldpath=newpath:... 重新设置链接库路径（只有所有依赖的库都已经被链接，才能完整的复现core dump 故障现场），参考dbx 的帮助文档获取更多信息。

列举源码信息

列举程序源码（list，需要在运行dbx 命令时使用-I 指明源码搜索路径，并使用-g 编译）或者汇编码（listi）：

(dbx) listi main

0x10001924 (main) 7c0802a6 mflr r0

0x10001928 (main+0x4) bfa1fff4 stmw

r29,-12(r1)

0x1000192c (main+0x8) 90010008 stw

r0,0x8(r1)

0x10001930 (main+0xc) 9421ffa0 stwu

r1,-96(r1)

0x10001934 (main+0x10) 83e20064 lwz

r31,0x64(r2)

0x10001938 (main+0x14) 90610078 stw

r3,0x78(r1)

0x1000193c (main+0x18) 9081007c stw

r4,0x7c(r1)

0x10001940 (main+0x1c) 83a20068 lwz

r29,0x68(r2)

列举变量内容

示例代码：

para++;

return 0;

}

int main(int argc, char* argv[])

{

struct sigaction s;

s.sa_handler = SIG_DFL;

s.sa_mask.losigs = 0;

s.sa_mask.hisigs = 0;

s.sa_flags = SA_FULLDUMP;

sigaction(SIGSEGV,&s,(struct sigaction

*) NULL);

char str[10];

g_test =0;

testfunc(g_test);

abort();

}

# xlC test.C -g

以全局变量g_test 举例：

#print g_test 显示g_test 的取值

#print sizeof(g_test) 显示g_test 的大小

#whatis g_test 显示g_test 的类型

#print &g_test 显示g_test 的地址

#&g_test/16x 显示从g_test 的地址开始处，连续16 个WORD（?byte）的取值

如果没有使用-g 编译，则不能动态获取g_test 的类型、大小等信息，但能够得到g_test 的地址，并查询该地址所在区域存储空间的值。

例如：

列举寄存器内容

列举寄存器内容：

(dbx) registers

如下模拟一个简单的core dump，对0 地址赋值引发core dump 的问题：# dbx ./a.out core

Type 'help' for help.

warning: The core file is not a fullcore.

Some info may

not be available.

[using memory image in core]

reading symbolic information ...warning:

no source compiled with -g

Segmentation fault in main at 0x10000348

0x10000348 (main+0x18) 90640000 stw

r3,0x0(r4)

(dbx) where

main(0x1, 0x2ff22ccc) at 0x10000348

(dbx) registers

$r0:0x00000000 $stkp:0x2ff22bf0

$toc:0x20000414 $r3:0x00000012

$r4:0x00000000 $r5:0x2ff22cd4

$r6:0xdeadbeef $r7:0x2ff22ff8

$r8:0x00000000 $r9:0x04030000

$r10:0xf0577538 $r11:0xdeadbeef

$r12:0xdeadbeef $r13:0xdeadbeef

$r14:0x00000001 $r15:0x2ff22ccc

$r16:0x2ff22cd4 $r17:0x00000000

$r18:0xdeadbeef $r19:0xdeadbeef

$r20:0xdeadbeef $r21:0xdeadbeef

$r22:0xdeadbeef $r23:0xdeadbeef

$r24:0xdeadbeef $r25:0xdeadbeef

$r26:0xdeadbeef $r27:0xdeadbeef

$r28:0xdeadbeef $r29:0xdeadbeef

$r30:0xdeadbeef $r31:0xdeadbeef

$iar:0x10000348 $msr:0x0000d0b2

$cr:0x22282489 $link:0x100001b4

$ctr:0xdeadbeef $xer:0x20000020

Condition status = 0:e 1:e 2:e 3:l 4:e 5:g

6:l 7:lo

[unset $noflregs to view floating point

registers]

[unset $novregs to view vector registers]

in main at 0x10000348

0x10000348 (main+0x18) 90640000 stw

r3,0x0(r4)

(dbx) print $r3

0x00000012

(dbx) print $r4

(nil)

这个例子比较简单，从最后汇编指令“stw r3,0x0(r4)”就可以简单的看到程序core dump 是因为向0 地址（0+r4）存入18（r3 寄存器值）造成。

查看多线程相关信息

如果以下环境变量采用默认的OFF 值，则系统会完全禁止适当的调试列表，这意味着dbx 命令将显示不出任何对象：

AIXTHREAD_MUTEX_DEBUG

AIXTHREAD_COND_DEBUG

AIXTHREAD_RWLOCK_DEBUG

可以使用

export AIXTHREAD_MUTEX_DEBUG=ON

打开AIXTHREAD_MUTEX_DEBUG。

查看线程信息

(dbx) print $t1 // 打印t1 线程的基本信息

(dbx) attribute

(dbx) condition

(dbx) mutex

(dbx) rwlock

(dbx) thread

例如：

(thread_id = 1, state_u = 4, priority = 60, policy = other, attributes = 0x20001078)

切换当前线程（默认当前线程为收到core 触发信号所在线程）

(dbx) thread current [tid]

例如（> 表明core dump 时的当前线程）：

(dbx)thread

thread state-k wchan state-u k-tid mode

held scope function

$t1 wait 0x31bbb558 running 10321 k no pro

_ptrgl

$t2 wait 0x311fb958 running 6275 k no pro

_ptrgl

>$t3 run running 6985 k no pro _p_nsleep

$t4 wait 0x31bbbb18 running 6571 k no pro

_ptrgl

$t5 wait 0x311fb9d8 running 7999 k no pro

_ptrgl

$t6 wait 0x31bf8f98 running 8257 k no pro

_ptrgl

$t7 wait 0x311fba18 running 8515 k no pro

_ptrgl

$t8 wait 0x311fb7d8 running 8773 k no pro

_ptrgl

$t9 wait 0x311fbb18 running 9031 k no pro

_ptrgl

$t10 wait 0x311fb898 running 9547 k no pro

_ptrgl

$t11 wait 0x311fb818 running 9805 k no pro

_ptrgl

$t12 wait 0x311fba58 running 10063 k no

pro _ptrgl

$t13 wait 0x311fb8d8 running 10579 k no

pro _ptrgl

(dbx) thread current 3

(dbx) where

_p_nsleep(??, ??) at 0xd005f740

raise.nsleep(??, ??) at 0xd022de3c

sleep(??) at 0xd0260344

helper(??) at 0x100005ac

(dbx) thread current 4

warning: Thread is in kernel mode, not all

registers can be accessed.

(dbx) where

ptrgl._ptrgl() at 0xd020e470

raise.nsleep(??, ??) at 0xd022de3c

core dump 分析的局限性

不要期待能依赖core dump 分析解决所有的问题，下面是一个简单的模拟缓冲区溢出的例子，在这个例子中由于缓冲区溢出覆盖了调用栈信息，从而完全丢失了定位依据：

root@/tmp#>xlC test.C -g -o test2

root@/tmp#>

root@/tmp#>./test

input str!

012345678901234567890123456789

Segmentation fault(coredump)

root@/tmp#>dbx ./test2 core

Type 'help' for help.

[using memory image in core]

reading symbolic information ...

Segmentation fault in test2. at 0x34353634

0x34353634 (???) warning: Unable to access

address 0x34353634 from core

(dbx) where