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 设置示例 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| //test.C
#include <iostream>
#include <signal.h>
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 <core 路径以及名称 > < 可执行文件以及名称 >，例如 snapcore ./core ./a.out，然后在 /tmp/snapcore 下取下相应的 .pax.Z 文件。
正常的收集过程应该如下 :
snap core 收集过程 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| # 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
#
|
|
