AIX下core dump定位简介
了解转储(dump)设备
了解转储（dump）设备David Tansley, 系统管理员, Ace Europe2012 年7 月30 日如果发生意外，IBM AIX® 操作系统会崩溃，此时您可能希望能够自动搜集相关信息。
利用转储（dump）设备，可在这些设备上部署核心转储功能，从而准备转移到IBM 支持。
简介如果由于意外事件导致系统崩溃，则会发生核心转储。
事实上，并非总在出现系统崩溃时才发生核心转储。
然而，在本文中，假定系统崩溃是由于严重事件或用户强制性动作所引起的。
转储包含了达到崩溃时内存的内容。
就其本质而言，崩溃总是不期而至，因而当崩溃发生时，系统管理员还是应当事先做好防范措施。
能够确定崩溃的发生是否是由系统重启引起，此时在错误日志里存在具有标签为SYSDUMP的条目。
在本演示中，我使用的是AIX 7.1。
不过，我所讨论的原理也适用于AIX 5.3 和 6.1。
回页首做好准备要想防范意外的系统崩溃，需要确保具有转储设备逻辑卷(LV)，用于在系统恢复时存放转储。
然而，如果转储设备不可用，那么应该指定第二转储设备来存放转储。
可能人们并不关心系统崩溃何时发生，因而也对进一步研究转储文件不感兴趣。
这完全取决于系统所有者。
但是，为保障系统正常运行，在rootvg 中包含主转储设备是很好的做法，也是很有必要的。
可为转储设备执行镜像，但是，IBM AIX 支持对此发出警告。
这是因为崩溃可能会被执行镜像或同步相关，这会导致转储设备上的镜像无效。
在某些情况下，转储文件仅会被复制到镜像转储设备（位于镜像磁盘中）的其中一个副本，当系统重启时，很可能仅恢复转储文件副本一半的内容，最好的做法是，将主转储设备放到一个非镜像的磁盘中，将第二设备放到另一个非镜像磁盘中。
然而，对rootvg 转储设备执行镜像比较常见。
只要第二转储设备不在分页空间中，或不在磁带设备之类的外部设备中，则它可以位于rootvg 内部，也可位于其外部。
回页首转储设备参考资料学习∙访问AIX 7.1 信息中心，了解更多信息。
AIX系统core文件
Ldd 可以查看程序调用了哪些库文件。
当进程在异常终止运行时，系统会把该进程对应的地址空间中的数据写到core文件中（这个过程被称为dump），以便程序员对其进行分析，找出进程异常终止的原因。
缺省情况下，异常终止的进程在启动它的当前目录下产生core文件。
在AIX 4.3.3中，所有的core文件的文件名都是core，如果不只一个程序产生dump或者相同的程序dump多次，它们都会产生相同文件名的core文件，那么就会丢失比较早的core 文件。
从AIX 5.1开始，改变了core文件的命名方法，使得每一个core文件拥有惟一的文件名，从而避免了新的core文件覆盖旧的core文件，这个特色更加有助于程序员调试和跟踪运行失败的程序。
默认情况下，一个core文件的文件名是core。
要使用AIX 5L中core文件命名的新方法，就要把CORE_NAMING环境变量的值设置为yes。
在AIX 5L中，把当前用户的CORE_NAMING环境变量的值设置成yes之后，随后启动的进程产生的core文件名才能惟一的。
新的core文件名的格式是core.pid.ddhhmmss。
其中pid是进程号，dd是当前月份中的日子，hh表示小时，mm表示分，ss表示秒。
对于一个占用内存资源很大的进程产生的core文件也非常大，因此如果经常有进程产生core文件，而core文件名都不相同，那么产生的core就会占用非常多的文件系统空间，所以系统管理员要定期为程序员收集这些core文件，并删除这些文件。
在AIX 5.3中，用户可以设置产生压缩的core文件和指定一个目录来保存core文件，用lscore命令查看当前用户或指定用户的core设置，例如：$ lscore compression: off path specification: off corefile location: not set naming specification: off $要查看peter用户的core设置，命令是lscore peter。
AIX 下的 core dump 分析入门
/developerworks/cn/aix/library/0806_chench_core/ (1 of 13)2010-5-2 17:04:24
AIX 下的 core dump 分析入门
结合 core 文件以及可执行程序，来分析问题所在。
注：由于进程信号处理本质上是异步的，应用进程注册的信号处理函数中使用的例程需要保证 是异步信号安全的，例如不能使用诸如 pthread_ 开头的例程。
正常的收集过程应该如下 :
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
使用DBX分析AIX下的 CoreDump
使用DBX分析AIX 下的CoreDumpPS:Where can you get dbx?It is part of bos.adt.debug# lslpp -w /usr/bin/dbxFile Fileset Type-------------------------------------------/usr/bin/dbx bos.adt.debug Symlink以下转自/?6141/viewspace-18882I core dump 分析入门AIX专家俱乐部E ?!CR8Z#S)[环境变量设置`#X`4\]9h|8]0;Uy%D]6sQ.i9O0 可以通过/etc/security/limits 文件对各用户的基本配置参数包括core 大小进行限制。
或者通过ulimit 更改当前环境下的core 大小限制。
AIX专家俱乐部vF?I9u:B1@]!HCc\!v_J-r)r3U0 默认情况下应用进程生成core dump 时都使用文件名core。
为了避免同一工作目录下的进程core 相互覆盖可以定义环境变量CORE_NAMING=true然后启动进程这样将生成名为core.pid.ddhhmmss 的文件。
可以使用file core 命令查看core 是哪个进程产生的。
:EvFu#O@$n*s)g0AIX专家俱乐部0U(p#k2_:J/} G"v$D.E默认情况下应用进程dump 时会包含所有的共享内存如果dump 时想排除共享内存内容可以在启动进程之前设置环境变量CORE_NOSHM=true.R1I rjg09kkS%v!@6o0 系统有一个参数fullcore 用于控制是否在程序coredump 时生成完整的core。
为避免信息丢失建议打开fullcore。
可以使用lsattr –El sys0 查询是否将fullcore 打开使用chdev -l sys0 -a fullcore=true 将fullcore 状态更改为打开。
应用程序运行时产生coredump故障处理
应用程序运行时产生coredump故障处理环境：操作系统：AIX Common 数据库：无关应用程序：32-bit症状：客户应用结息程序在运行过程中产生coredump。
程序故障与处理数据量有关，当把结息网点分成两批，可以顺利完成。
解决方法：应用程序的问题本来不属于我们维保的范畴，因为客户关系比较好，开发商太极公司也是我们的友军，抱着试试看的态度来解决。
用svmon跟踪程序的执行，发现其在运行期间，work process private部分的内存增长速度非常快，并且很明显地，接近65536页的时候即发生core dump。
这表明程序故障与内存的过度使用有关，达到256MB阀值时溢出。
work process private与用户程序的堆、栈有关，其中堆常为malloc系统调用分配的内存空间。
这里与ulimit设置无关（已经设置为unlimited），与AIX 32位程序的内存分配行为有关。
32位程序最多可以使用16个内存段，其中segment 2~C用户可用作堆栈和共享内存，默认仅使用segment 2存放程序堆栈数据，最大值为256MB，所以默认情况下用户程序最多只能分配256MB的堆内存。
而这个默认行为，可以通过在执行程序前，设置LDR_CNTRL环境变量来调节堆栈部分和共享内存的比例，例如：LDR_CNTRL=MAXDATA=0x30000000，设置了堆栈内存空间最多可使用3个内存段，共768MB 内存。
下面是一个测试的例子：# include <stdio.h>main (){int i;unsigned char *p;i=0;while ( i < 20 ){printf ( "i=%d\n", i );/* 32M */p=(unsigned char *)malloc(33554432);memset(p,'\0',33554432);i=i+1;sleep(1);}sleep(120);}直接运行该程序，在i=7之后产生coredump，采用下面的方式执行命令：# LDR_CNTRL=MAXDATA=0x3000000 ./testmalloc程序能够正常执行结束运行，同时运行的svmon显示程序已经使用到了256MB以上的堆空间。
coredump文件生成过程
coredump文件生成过程
生成core dump文件通常发生在程序发生严重错误或崩溃时，
它记录了程序在崩溃时的内存状态和调用栈信息，有助于开发人员
分析问题并进行调试。
下面我会从多个角度来解释core dump文件
生成的过程。
1. 产生原因，当程序发生严重错误，比如访问非法内存、除零
错误、段错误等，操作系统会向程序发送一个信号，通常是SIGSEGV（段错误）或SIGABRT（异常终止），程序在收到信号后会
尝试生成core dump文件。
2. 操作系统设置，在大多数操作系统中，生成core dump文件
需要进行相应的设置。
在Linux系统中，可以使用ulimit命令设置core文件大小限制，使用sysctl命令设置core文件的名称格式和
存储路径。
在Windows系统中，可以通过控制面板中的系统属性进
行设置。
3. 内存转储，当程序接收到信号时，操作系统会将程序的内存
状态以及相关信息写入core dump文件中。
这包括程序的内存布局、寄存器状态、堆栈信息等。
4. 存储位置，生成的core dump文件通常会被存储在当前工作目录或指定的路径下，具体存储位置取决于系统设置和程序运行时的环境变量。
5. 调试分析，生成core dump文件后，开发人员可以使用调试工具（如gdb、windbg等）加载core dump文件，重现程序崩溃时的状态，并进行分析和调试，以找出程序中的错误和异常。
总的来说，生成core dump文件是程序在发生严重错误时的一种自我保护机制，它记录了程序崩溃时的状态信息，为开发人员提供了重要的调试和分析数据，有助于快速定位和解决问题。
coredump的使用方法
coredump的使用方法
通常情况下coredmp包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。
可以理解为把程序工作的当前状态存储成一个文件。
许多程序和操作系统出错时会自动生成一个core文件。
一般Linux系统中，默认是不会产生core dump文件的。
（以下需要切换到root用户进行命令执行）
1coredump的开关和core文件大小限制
1.core文件的名称和生成路径
core文件名如果不设置，则每次产生的core文件名相同，会覆盖原来的core文件，因此需要对core文件名进行设置，设置方法有两种，具体如下：
2.生成core文件并使用gdb进行查看。
coredump文件的生成方式
coredump文件的生成方式
Core dump文件是在程序发生严重错误（如段错误、内存访问
越界等）时，操作系统将程序当前的内存状态以文件的形式保存下
来的一种机制。
生成core dump文件的方式可以通过以下几种途径：
1. 通过ulimit命令设置core dump文件大小限制，可以使用ulimit命令来设置core dump文件的大小限制，使用ulimit -c unlimited命令可以将core dump文件的大小限制设置为无限制，
这样当程序发生错误时就会生成core dump文件。
2. 在程序中使用系统调用设置，在程序中可以通过调用系统函
数来设置生成core dump文件的方式，比如使用ulimit函数设置core dump文件大小限制，或者使用prctl函数设置生成core dump
文件的路径等。
3. 通过操作系统的配置文件设置，在一些操作系统中，可以通
过修改配置文件（如/etc/security/limits.conf）来设置生成
core dump文件的大小限制和路径等参数。
4. 使用特定的调试工具，在调试程序时，可以使用特定的调试
工具（如gdb）来设置程序发生错误时生成core dump文件，通过gdb工具可以设置生成core dump文件的路径和大小限制等参数。
总的来说，生成core dump文件的方式可以通过操作系统的设置、程序中的系统调用、配置文件的修改以及调试工具的使用等途径来实现。
不同的操作系统和调试工具可能会有不同的设置方法，需要根据具体情况进行选择和配置。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Core dump 基本知识
本节主要探讨 core dump 产生的背景知识。对这部分不感兴趣的读者可以直接阅读第二章，了 解基本的 core dump 定位手段。
起源
软件是人思维的产物。智者千虑，必有一失，人的思维总有缺陷，反映到软件层面上就是程序 bug。程序 bug 的终极体现就是 core dump，core dump 是软件错误无法恢复的产物。
Segmentation fault in raise at 0xd022e1e4
0xd022e1e4 (raise+0x40) 80410014
lwz r2,0x14(r1)
显示出 core 发生时，当前进程执行到的位置（-g 编译的情况下能够看到具体的行）：
(dbx) where raise(??) at 0xd022e1e4 main(0x1, 0x2ff22d48) at 0x100019c4
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 信息。
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 ..
环境变量设置
可以通过/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， 参考如下测试程序：
系统 dump 生成过程
系统异常 dump 的具体过程与应用进程类似，但由于更接近底层，为了避免问题所在的资源 （例如文件系统）正好包含在生成 dump 需要使用的资源中，造成 dump 无法生成，操作系统一 般会用最简单的方式来生成 dump。例如系统内存小于 4G 的情况下，一般直接将 dump 生成在 pagingspace 中；大于 4G 时，会建专门的 lg_dumplv 逻辑卷（裸设备）保存 dump 信息。在系统
Checking for available space ...
Available space is 807572 kbytes
pass1 complete.
pass2() in progress ....
Collecting fileset information .
Collecting error report of CORE_DUMP errors ..
生成过程
进程 core dump 与系统 dump 的产生，从程序原理上来说是基本一致的。dump 的生成一般是在 系统进行中断处理时进行的，下面简单介绍一下中断机制。
操作系统的中断机制
操作系统是由中断驱动的。广义的中断一般分为两类，中断(Interrupts)和异常(Exceptions)。中 断可在任何时候发生，与 CPU 正在执行什么指令无关，中断主要由 I/O 设备、处理器时钟（分 时系统依赖时钟中断划分时间片）或定时器等硬件引发，可以被允许或取消。而异常是由于 CPU 执行了某些指令引起的，可以包括存储器存取违规、除 0 或者特定调试指令等，内核也将 系统服务视为异常。系统对这两类中断的处理基本上是相同的。 每个中断都会唯一对应到一个中断处理程序，在该中断触发时，相应的处理程序就会被执行。 例如应用进程进行系统调用时，就会触发一个软件异常，进入中断处理函数，完成从用户态到 系统态的迁移并进入相应系统调用的入口点。应用进程 coredump 也是一个类似的过程t
lslpp.out
core
snapcore_352276.pax
#
使用 dbx 分析 core dump 的例子
dbx 是 AIX 下基于命令行界面的源码级调试工具。本文档只提供一些基本的 dbx 分析指令，详 细内容请参考“General Programming Concepts: Writing and Debugging Programs”关于 dbx 的描述。
应用进程 core dump 生成过程
在进程运行出现异常行为时，例如无效地址访问、浮点异常、指令异常等，将导致系统转入内 核态进行异常处理（即中断处理），向相应的进程发出特定信号例如 SIGSEGV、SIGFPE、 SIGILL 等。如果应用进程注册了相应信号的处理函数（例如可通过 sigaction 注册信号处理函 数），则调用相应处理函数进行处理（应用程序可以选择记录信息后生成 core dump 并退 出）；否则将采取默认动作，例如 SIGSEGV 的默认动作是生成 core dump 并退出程序。 进程 coredump 的时候，操作系统会将进程终止并释放其占用的资源，正常情况下，应用进程 coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程，则 这些进程会受到影响，至于后果则视其对此异常的具体处理而定。
fullcore 设置示例
//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);
Creating readme file ..
Creating archive file ...
Compressing archive file ....
pass2 completed.
Snapcore completed successfully. Archive created in /tmp/snapcore.
初步分析
#dbx <program name> core
示例：
# dbx ./test 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
core dump 信息收集
如果可能,直接在发生 coredump 的机器上用 dbx 分析出结果,这样是最方便的分析方法. 这种情况 下注意不要直接以 root 用户登录然后用 dbx 分析,而必须在应用程序所属的用户下进行此操作,因 为 core 可能需要依赖应用程序运行时对应环境下的某些库, 这样就要借助应用程序的环境变量. 如果需取回生产机上的 core 信息在实验室分析,则需要搜集一些相关信息. 进程 core 分析一般至 少需要依赖应用可执行程序，有时还需要包括一些运行时动态库信息。如果需要收集 core 相关 的完整信息，可运行 snapcore <core 路径以及名称> <可执行文件以及名称>， 例如 snapcore ./core ./a.out， 然后在/tmp/snapcore 下取下相应的.pax.Z 文件。 正常的收集过程应该如下: