AIX 下的 core dump 分析入门
AIX下core dump定位简介
core dump 信息收集
如果可能,直接在发生 coredump 的机器上用 dbx 分析出结果,这样是最方便的分析方法. 这种情况 下注意不要直接以 root 用户登录然后用 dbx 分析,而必须在应用程序所属的用户下进行此操作,因 为 core 可能需要依赖应用程序运行时对应环境下的某些库, 这样就要借助应用程序的环境变量. 如果需取回生产机上的 core 信息在实验室分析,则需要搜集一些相关信息. 进程 core 分析一般至 少需要依赖应用可执行程序,有时还需要包括一些运行时动态库信息。如果需要收集 core 相关 的完整信息,可运行 snapcore <core 路径以及名称> <可执行文件以及名称>, 例如 snapcore ./core ./a.out, 然后在/tmp/snapcore 下取下相应的.pax.Z 文件。 正常的收集过程应该如下:
初步分析
#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
使用DBX分析AIX下的 CoreDump
使用DBX分析AIX 下的CoreDump
PS:
Where can you get dbx?
It is part of bos.adt.debug
# lslpp -w /usr/bin/dbx
File Fileset Type
-------------------------------------------
/usr/bin/dbx bos.adt.debug Symlink
以下转自/?6141/viewspace-18882
I 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@]!HC
c\!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.
coredumpctl使用
coredumpctl使用
使用coredumpctl进行核心转储分析
概述
核心转储是在系统发生崩溃或故障时生成的一种文件,用于记录系统状态和进程信息。通过分析核心转储文件,我们可以了解崩溃原因,帮助排除故障并改进系统稳定性。coredumpctl是一个命令行工具,可以帮助我们管理和分析核心转储文件。
1. 安装coredumpctl
在大多数Linux发行版中,coredumpctl已经预装。如果您的系统没有安装coredumpctl,可以通过以下命令安装:
```
sudo apt install systemd-coredump
```
2. 查看核心转储文件
要查看系统中的核心转储文件,可以使用以下命令:
```
coredumpctl list
```
此命令将列出所有可用的核心转储文件,包括文件名、PID、时间戳和所属用户。您可以根据需要选择特定的核心转储文件进行分析。
3. 分析核心转储文件
要分析核心转储文件,可以使用以下命令:
```
coredumpctl gdb
```
这将使用GNU Debugger (GDB)打开最新的核心转储文件。您可以使用GDB命令进行进一步的调试和分析。
4. 显示核心转储文件信息
要查看核心转储文件的详细信息,可以使用以下命令:
```
coredumpctl info <coredump文件名>
```
通过此命令,您可以获得关于核心转储文件的各种信息,包括进程名称、进程ID、信号、崩溃时间和核心转储文件大小等。
5. 导出核心转储文件
您可以将核心转储文件导出到其他位置以进行进一步分析,可以使用以下命令:
core文件分析
core⽂件分析
内容提要:
主要包含两部分内容:
1,core⽂件描述
2,core⽂件分析
说明:
⼀,Core ⽂件描述
Coredump 在unix 平台是⾮常容易出现的⼀种错误形式,直接表现形式为core ⽂件, core ⽂件产⽣于当前⽬录下,通常,象内存地址错误、⾮法指令、总线错误等会引起coredump ,core ⽂件的内容包含进程出现异常时的错误影像。如果错误进程为多线程并且core ⽂件的⼤⼩受限于ulimit 的系统限制,则系统只将数据区中错误线程的堆栈区
复制到core ⽂件中。
应当注意,从AIX 5L 版本5.1 开始core ⽂件的命名格式可以通过环境变量CORE_NAMING 设置,其格式为:core.pid.ddhhmmss ,分别代表为:
pid :进程标⽰符
dd :当前⽇期
hh :当前⼩时
mm :当前的分钟
ss :当前的秒
core ⽂件的缺省格式为⽼版本的格式,coredump ⽂件的内容按照以下的顺序组织:
1 ) core ⽂件的头部信息
定义 coredump 的基本信息,及其他信息的地址偏移量
2 ) ldinfo 结构信息
定义 loader 区的信息
3 ) mstsave 结构信息
定义核⼼线程的状态信息,错误线程的 mstsave 结构信息直接存储在 core ⽂件的头部区,此区域只对多线程的 程序有效,除错误线程外的其他线程的 mstsave 结构信息存与此区域。
4 ) 缺省的⽤户堆栈数据
存储 coredump 时的⽤户堆栈数据
5 ) 缺省的数据区域
存储⽤户数据区域信息
段错误(core dumped)
段错误 (core dumped)
当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。最常出现的,几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。
何谓core文件
当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。
使用core文件调试程序
看下面的例子:
#include
char *str = "test";
void core_test(){
str[1] ='T';
}
int main(){
core_test();
return0;
}
编译:
gcc –g core_dump_test.c -o core_dump_test
如果需要调试程序的话,使用gcc编译时加上-g选项,这样调试core文件的时候比较容易找到错误的地方。
执行:
./core_dump_test
段错误
运行core_dump_test程序出现了“段错误”,但没有产生core文件。这是因为系统默认core文件的大小为0,所以没有创建。可以用ulimit命令查看和修改core文件的大小。ulimit -c 0
ulimit -c 1000
ulimit -c 1000
-c指定修改core文件的大小,1000指定了core文件大小。也可以对core文件的大小不做限制,如:
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进行查看
AIX疑难问题分析过程
AIX疑难问题分析过程
1.1 1 与inode相关的几个命令
环境:(产品AIX,平台pSeries)
问题描述: 本文介绍了与inode相关的几个命令,及其使用方法. 解答:
inode是AIX操作系统中的一种数据结构,它包含了与文件系统中各个文件相关的一些重要信息,例如: > inode 编号 > 文件所在设备 > 属主的UID > 属主的GID > 文件的大小 > 文件的链接数目 > 最近一次修改的时间 > 最近一次访问的时间 > 最近一次更改的时间
下面介绍AIX中与inode相关的几个命令: 1. df命令 - 监视 inode的使用
当在AIX中创建一个文件系统时,将为 inode表分配一定的磁盘空间.每次在文件系
统中创建一个文件时,都会为该文件分配一个 inode.在df命令的输出中,可以查看各个文件系统中已使用的 inode的数目,以及文件系统中总体使用情况百分比: # df -m | head -6
Filesystem MB blocks Free %Used Iused %Iused Mounted on /dev/hd4 288.00 77.17 74% 12980 37% /
/dev/hd2 2528.00 109.54 96% 53299 58% /usr /dev/hd9var 80.00 6.64 92% 4764 70% /var /dev/hd3 464.00 365.88 22% 512 1% /tmp /dev/hd1 16.00 15.50 4% 55 2% /home
Core Dump详解
1. 什么是Core:
Sam之前一直以为Core Dump中Core是Linux Kernel的意思. 今天才发现在这里,Core是另一种意思:
在使用半导体作为内存的材料前,人类是利用线圈当作内存的材料(发明者为王安),线圈就叫作core ,用线圈做的内存就叫作core memory。如今,半导体工业澎勃发展,已经没有人用core memory 了,不过,在许多情况下,人们还是把记忆体叫作core 。
2. 什么是Core Dump:
我们在开发(或使用)一个程序时,最怕的就是程序莫明其妙地当掉。虽然系统没事,但我们下次仍可能遇到相同的问题。于是这时操作系统就会把程序当掉时的内存内容dump 出来(现在通常是写在一个叫core 的file 里面),让我们或是debugger 做为参考。这个动作就叫作core dump。
3. Core Dump时会生成何种文件:
Core Dump时,会生成诸如core.进程号的文件。
4. 为何有时程序Down了,却没生成Core文件。
Linux下,有一些设置,标明了resources available to the shell and to processes。可以使用#ulimit -a来看这些设置。 (ulimit是bash built-in Command)
-a All current limits are reported
-c The maximum size of core files created
-d The maximum size of a process鈥檚data segment
Segment Fault(core dump)调试方法
Coredump
关于程序core dump的调试方法简述:
首先,在程序不正常退出时,内核会在当前工作目录下生成一个core文件(是一个内存映像,同时加上调试信息)。使用gdb来查看core文件,可以指示出导致程序出错的代码所在文件和行数。这个能给debug带来极大方便。
查看core dump位置方法:"gdb ./app core".
故,我们需要gdb,可执行文件app,以及core文件。下面将根据这3个需求,依次得到它们;
一、
1,得到gdb;
其实这个是最简单的,Linux PC上gdb不用说了。Android的是~/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/b in/arm-linux-androideabi-gdb(其中~/opt/,与个人设置有关;android-ndk-r7与编译器版本有关,貌似android-ndk-r4没有toolchains目录,不知是否可以用gdbserver调试程序,当然这就不在本文档的讨论范围之内了).
2,得到可执行文件app
由于要使用gdb,所以app必须是"not stripped".Linux PC上"gcc hello.c"编译出来的a.out默认就是"not stripped".Android工程中jni目录下,我们使用"ndk-build"默认是"stripped"的。因此需要更改编译脚本:在~/opt/android-ndk-r7/build/core/中打开default-build-commands.mk文件,将"cmd-strip = $(PRIVATE_STRIP) --strip-unneeded $(call host-path,$1)"这一行注释掉.这一行就是做的"strip"操作。再用"ndk-build"编译就是"not stripped"的了。
oracle coredump
Core Dump杂记 作者:未知 时间:2005-09-13 23:03 出处: 责编:chinaitpower 摘要:Core Dump杂记 1、开启系统的Core Dump功能ulimit -c core_file_size_in_kb如果要关闭该功能core_file_size_in_kb为0就行了。2、设置Core Dump的核心转储文件目录和命名规则文件的命名规则放在/proc/sys/kernel/core_name_format文件中使用sysctl -w "kernel.core_name_format=/coredump/%n.core"上例的core文件放在/coredump目录下,文件名是进程名+.core以下是一些命名的格式说明%P The Process ID (current->pid) %U The UID of the process (current->uid) %N The command name of the process (current->comm) %H The nodename of the system (system_utsname.nodename) %% A "%" 3、分析核心转储文件程序如下:#include int main(){int i=0;int j=5;int tmp;for(; i < 10; i++, j--){tmp=i/j;printf("%d/%d=%dn", i, j, tmp);}}该程序运行到i=5时,会发生浮点运算错误(被除数等于0,j=0)编译上面的程序gcc -g main.c -o eg./eg发生core-dump后,如果核心转储文件是core.2098,执行下面的命令gdb eg core.2098可以看到当时的信息,此出不方便录入。4、杂项kill -l上面命令列出所有信号的名称和值kill -l val查询值为val的信号名称kill -l signame查询signame信号的值附录 A. IBM AIX中产生Core文件的方法(来源于IBM cn)Document #: 1311993F06001 环境:(产品,平台,机型,软件版本,等) 平台:RS 软件版本:AIX4.3 or later问题描述: 如果用户需要为一个应用进程产生一个完整的core文件用于分析,如何做?解答: 1. 前提条件在产生core文件之前,先要配置系统参数以确认系统可以产生一个完整的core文件。另外,文件系统中还需要有足够的剩余空间用于存放所产生的core文件。core文件通常存放在进程属主用户的主目录中。 2. 什么时候要产生完整地Core文件缺省情况下,进程不会产生一个完整的core文件。如果需要跟踪调试一个应用的共享内存段中的数据,特别是线程堆栈中的数据,则需要产生一个完整的core dump文件用于分析。 3. 若需要产生完整的core文件信息,首先需要以root身份执行下面的命令: # chdev -l sys0 -a fullcore=true 上述命令也可以通过smitty来完成: smitty --> System Environments --> Change/ Show Characteristics of Operating System Change/ Show Characteristics of Operating System Maximum number of PROCESSES allowed per user [128] Maximum number of pages in block I/O BUFFER CACHE [20] Maximum Kbytes of real me
关于core dump的心得
从接触unix开始就一直听到和遇到core dump,特别是刚学着使用C语言在编写程序的时候,core dump更是时不时就会不请自来。记得当时刚写应用的时候,提交程序时最怕的就是在运行过程时遇到core dump,对于BOSS核心系统,特别是使用静态应用进程,如果一个相对频繁一点的交易导致core dump,那么毫无疑问,除了赶紧定位错误改程序外,重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的,就是程序中一个小小的未注意到或者未测试到的一个疏忽。
虽然常常遇到core dump,不过很长时间内,都是出于知道这个名字,知道它导致的后果,知道一部分导致它出现的原因,其他的就都不甚了了了。说起来,就是自己太懒了,懒得看书......少壮不努力啊。看过一则统计,说60岁以上的老人,超过70%都后悔少壮不努力,不知统计的数据能否反映整个社会的情况。不过总的来说,这句古话还是有些道理的。大家不要学我。哈哈
core dump,翻译过来讲,就是核心转储。大致上就是指,如果由于应用错误,如浮点异常、指令异常等,操作系统将会转入内核的异常处理,向对应的进程发送特定的信号(SIGNAL),如果进程中没有对这些信号进行处理,就会转入默认的处理,core dump就是其中的一种。如果进程core dump,系统将会终止该进程,同时系统会产生core文件,以供调试使用。这个core文件其实就是内存的映像,即进程执行的时候内存的内容,也就是所谓的core dump。平常大家说某某进程core dump了,其实主要的意思就是说:某某进程因为错误而被系统自动终止了。
aix下core文件的使用
aix下core文件的使用
aix下core 文件的使用(转载)
Q:在AIX系统中,经常会看到文件名为core的文件,这个文件有用处吗?如果有用,怎么使用?
A:当进程在异常终止运行时,系统会把该进程对应的地址空间中的数据写到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 $
AIX Dump Deivce
AIX Dump Deivce 使用1. 估算dump设备所需要的大小# sysdumpdev -e0453-041 Estimated dump size in bytes: 9814671362. 系统会定时检测dump device的大小,见root的cron:0 15 * * * /usr/lib/ras/dumpcheck >/dev/null 2>&1如果发现dump device空间不够大,会报错errpt,例如:837E0DE7 1112202205 P O dumpcheck The largest dump device is too small.对于这样的错误信息,一般都是主dump设备的空间太小。3. 修改dump device大小的方法:3.1 查看当前系统的dump device# sysdumpdev -lprimary /dev/lg_dumplvsecondary /dev/sysdumpnullcopy directory /var/adm/rasforced copy flag TRUEalways allow dump FALSEdump compression ON在AIX 52以上,主dump设备都是建立在rootvg上的一个叫lg_dumplv的逻辑卷上。3.2 修改主dump设备的位置可以将主dump设备临时指定到/dev/hd6(swap)或者/dev/sysdumpnull(空dump设备,也就是没有)-P primary dump device-p Makes permanent the dump device specified by -p or -s flags.#sysdumpdev -P -p /dev/hd6primary /dev/hd6secondary /dev/sysdumpnullcopy directory /var/adm/rasforced copy flag TRUEalways allow dump FALSEdump compression ON3.3 扩展lg_dumplv的大小或者是重新以大的尺寸创建该lv# extendlv lg_dumplv xxx3.4 改变主dump设备回lg_dumplv# sysdumpdev -P -p /dev/lg_dumplvprimary /dev/lg_dumplvsecondary /dev/sysdumpnullcopy directory /var/adm/rasforced copy flag TRUEalways allow dump FALSEdump compression ON3.5 运行检测程序,看是否还报错。#/usr/lib/ras/dumpcheck4. 对于根盘镜像的系统如果paging swap和dump device不同,系统不会mirror(The system dump devices (primary /dev/hd6 and secondary /dev/sysdumpnull)should not be mirrored.)# lsvg -l rootvgrootvg:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINThd5 boot 1 2 2 closed/syncd N/Ahd6 paging 244 488 2 open/syncd N/Ahd8 jfs2log 1 2 2 open/syncd N/Ahd4 jfs2 8 16 2 open/syncd /hd2 jfs2 40 80 2 open/syncd /usrhd9var jfs2 40 80 2 open/syncd /varhd3 jfs2 16 32 2 open/syncd /tmphd1 jfs2 40 80 2 open/syncd /homehd10opt jfs2 80 160 2 open/syncd /optlg_dumplv sysdump 16 16 1 open/syncd N/A建议:在hdisk0和hdisk1上分别创建两个dump device,例如:给rootvg里面的每一个硬盘增加一个dump devicemklv -t sysdump -Y sysdumplv00 rootvg 50 hdisk0mklv -t sysdump -Y sysdumplv01 rootvg 50 hdisk1sysdumpdev -P -p /dev/sysdumplv00sysdumpdev -P -s /dev/sysdumplv01上面的两个命令可能应
关于Segmentationfault(coredumped)
关于Segmentationfault(coredumped)
有的程序可以通过编译,但在运⾏时会出现Segment fault(段错误)。这通常都是指针错误引起的。但这不像编译错误⼀样会提⽰到⽂件⼀⾏,⽽是没有任何信息。⼀种办法是⽤gdb的step, ⼀步⼀步寻找。但要step⼀个上万⾏的代码让⼈难以想象。我们还有更好的办法,这就是core file。
如果想让系统在信号中断造成的错误时产⽣core⽂件, 我们需要在shell中按如下设置:
#设置core⼤⼩为⽆限 ulimit -c unlimited
#设置⽂件⼤⼩为⽆限 ulimit unlimited
发⽣core dump之后,⽤gdb进⾏查看core⽂件的内容, 以定位⽂件中引发core dump的⾏:
gdb [exec file] [core file]
如: gdb ./test test.core 在进⼊gdb后,⽤bt命令查看backtrace以检查发⽣程序运⾏到哪⾥,来定位core dump的⽂件->⾏。
另外需要注意的是,如果你的机器上跑很多的应⽤,你⽣成的core⼜不知道是哪个应⽤产⽣的,你可以通过下列命令进⾏查看:file core
⼏个问题:
1. 什么是Core:
在使⽤半导体作为内存的材料前,⼈类是利⽤线圈当作内存的材料(发明者为王安),线圈就叫作 core ,⽤线圈做的内存就叫作 core memory。如今,半导体⼯业澎勃发展,已经没有⼈⽤core memory 了,不过,在许多情况下,⼈们还是把记忆体叫作 core 。
有关aio引起AIX宕机的core_dump分析
有关aio引起AIX宕机的core_dump分析
2008.03.27
前些日子,客户的S7A主机发生了几次宕机,产生了CORE_DUMP文件,下面是利用crash命令分析宕机原因的过程
pwd
/
# hostname
s7a01
# cd /var/adm/ras
# ls -l 查看core文件名称
total 395133
-rw-rw-r-- 1 root system 4226 Apr 02 2003 BosMenus.log
-rw-r--r-- 1 root system 2 Jan 07 2000 SRCSemID
-rw------- 1 root system 8192 May 20 13:35 bootlog
-rw-r--r-- 1 root system 8388 Apr 02 2003 bosinst.data
-rw-rw-r-- 1 root system 16384 Apr 02 2003 bosinstlog
--w------- 1 root system 2 May 16 15:47 bounds
-rw-r--r-- 1 bin bin 197206 Jan 01 1970 codepoint.cat
-rw--w--w- 1 root system 16384 May 20 15:52 conslog
--w------- 1 root system 21 May 16 15:47 copyfilename
-rw-r--r-- 1 root system 57078 Apr 02 2003 devinst.log
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
core dump 信息收集
如果可能 , 直接在发生 coredump 的机器上用 dbx 分析出结果 , 这样是最方便的分析方法 . 这 种情况下注意不要直接以 root 用户登录然后用 dbx 分析 , 而必须在应用程序所属的用户下进行 此操作 , 因为 core 可能需要依赖应用程序运行时对应环境下的某些库 , 这样就要借助应用程序 的环境变量 .
std::cout << " input str!\n" << std::endl; std::cin >> str; return 0;
http://www.ibm.com/developerworks/cn/aix/library/0806_chench_core/ (2 of 13)2010-5-2 17:04:24
http://www.ibm.com/developerworks/cn/aix/library/0806_chench_core/ (3 of 13)2010-5-2 17:04:24
AIX 下的 core dump 分析入门
# 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 #
http://www.ibm.com/developerworks/cn/aix/library/0806_chench_core/ (1 of 13)2010-5-2 17:04:24
AIX 下的 core dump 分析入门
结合 core 文件以及可执行程序,来分析问题所在。
注:由于进程信号处理本质上是异步的,应用进程注册的信号处理函数中使用的例程需要保证 是异步信号安全的,例如不能使用诸如 pthread_ 开头的例程。
AIX 下的 core dump 分析入门
中国 [选择] 使用条款
首页
产品
服务与解决方案
dW •••• 支持与下载
个性化服务
developerWorks 中国 本文内容包括:
Core dump 基本知识 应用进程 core dump 分 析 系统 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 .. 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
每个中断都会唯一对应到一个中断处理程序,在该中断触发时,相应的处理程序就会被执行。 例如应用进程进行系统调用时,就会触发一个软件异常,进入中断处理函数,完成从用户态到 系统态的迁移并进入相应系统调用的入口点。应用进程 coredump 也是一个类似的过程。
应用进程 core dump 生成过程
在进程运行出现异常行为时,例如无效地址访问、浮点异常、指令异常等,将导致系统转入内 核态进行异常处理(即中断处理),向相应的进程发出特定信号例如 SIGSEGV、SIGFPE、 SIGILL 等。如果应用进程注册了相应信号的处理函数(例如可通过 sigaction 注册信号处理函 数),则调用相应处理函数进行处理(应用程序可以选择记录信息后生成 core dump 并退 出);否则将采取默认动作,例如 SIGSEGV 的默认动作是生成 core dump 并退出程序。
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);
默认情况下,应用进程生成 core dump 时都使用文件名 core。为了避免同一工作目录下的进 程 core 相互覆盖,可以定义环境变量 CORE_NAMING=true,然后启动进程,这样将生成名 为 core.pid.ddhhmmss 的文件。可以使用 file core 命令查看 core 是哪个进程产生的。
系统 dump 生成过程
系统异常 dump 的具体过程与应用进程类似,但由于更接近底层,为了避免问题所在的资源 (例如文件系统)正好包含在生成 dump 需要使用的资源中,造成 dump 无法生成,操作系统 一般会用最简单的方式来生成 dump。例如系统内存小于 4G 的情况下,一般直接将 dump 生 成在 pagingspace 中;大于 4G 时,会建专门的 lg_dumplv 逻辑卷(裸设备)保存 dump 信 息。在系统重启的时候,如果设置的 DUMP 转存目录(文件系统中的目录)有足够空间,它将 会转存成一个文件系统文件,缺省情况下,是 /var/adm/ras/ 下的 vmcore* 这样的文件。
生成过程
进程 core dump 与系统 dump 的产生,从程序原理上来说是基本一致的。dump 的生成一般是 在系统进行中断处理时进行的,下面简单介绍一下中断机制。
操作系统的中断机制
操作系统是由中断驱动的。广义的中断一般分为两类,中断 (Interrupts) 和异常 (Exceptions)。 中断可在任何时候发生,与 CPU 正在执行什么指令无关,中断主要由 I/O 设备、处理器时钟 (分时系统依赖时钟中断划分时间片)或定时器等硬件引发,可以被允许或取消。而异常是由 于 CPU 执行了某些指令引起的,可以包括存储器存取违规、除 0 或者特定调试指令等,内核 也将系统服务视为异常。系统对这两类中断的处理基本上是相同的。
文档选项 打印本页
将此页作为电子邮 件发送
相关链接:
AIX and UNIX 技术文档 本节主要探讨 core dump 产生的背景知识。对这部分不感兴趣的读者可以直接阅读第二章,了
库
解基本的 core dump 定位手段。
来自百度文库
起源
软件是人思维的产物。智者千虑,必有一失,人的思维总有缺陷,反映到软件层面上就是程序 bug。程序 bug 的终极体现就是 core dump,core dump 是软件错误无法恢复的产物。
默认情况下,应用进程 dump 时会包含所有的共享内存,如果 dump 时想排除共享内存内容, 可以在启动进程之前设置环境变量 CORE_NOSHM=true.
系统有一个参数 fullcore 用于控制是否在程序 coredump 时生成完整的 core。为避免信息丢 失,建议打开 fullcore。可以使用 lsattr –El sys0 查询是否将 fullcore 打开,使用 chdev -l sys0 -a fullcore=true 将 fullcore 状态更改为打开。也可以在程序内部调用 sigaction 例程设置 fullcore,参考如下测试程序:
如果需取回生产机上的 core 信息在实验室分析 , 则需要搜集一些相关信息 . 进程 core 分析一 般至少需要依赖应用可执行程序,有时还需要包括一些运行时动态库信息。如果需要收集 core 相关的完整信息,可运行 snapcore <core 路径以及名称 > < 可执行文件以及名称 >,例如 snapcore ./core ./a.out,然后在 /tmp/snapcore 下取下相应的 .pax.Z 文件。
developerWorks 中国 > AIX and UNIX >
AIX 下的 core dump 分析入门
陈 炽卉 (chenchih@cn.ibm.com), 工程师, IBM 2008 年 6 月 12 日
本文简要介绍了 AIX 平台下 core dump 产生的原理以及相关定位方法。
Core dump 基本知识
进程 coredump 的时候,操作系统会将进程终止并释放其占用的资源,正常情况下,应用进程 coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程, 则这些进程会受到影响,至于后果则视其对此异常的具体处理而定。
由于相关指令已经包含在可执行文件中,core 文件一般只包含进程异常时相关的内存信息。其 格式可参考 /usr/include/sys/core.h 或者 AIX 帮助文档的“Files Reference”章节。我们一般需要
使用 dbx 分析 core dump 的例子
dbx 是 AIX 下基于命令行界面的源码级调试工具。本文档只提供一些基本的 dbx 分析指令,详 细内容请参考“General Programming Concepts: Writing and Debugging Programs”关于 dbx 的 描述。
AIX 下的 core dump 分析入门
}
寻找 core dump
应用进程的 core 产生在其当前工作目录下,可以在应用程序内部使用 chdir 函数切换当前工作 目录。使用 procwdx 命令可以查看进程的当前工作目录。系统的 core 生成在 lg_dumplv 下, 并在重启时转移到 /var/adm/ras/ 目录下(如果有足够空间的话,否则继续保留在 lg_dumplv, 并随时有可能被覆盖)。
初步分析
#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
系统 dump 一般可以通过升级微码、提高系统补丁级别、升级驱动等方式解决。
应用进程 core dump 分析
回页首
上一章我们介绍了 core dump 产生的基本原理。本章我们将针对 AIX 操作系统,介绍 core dump 定位相关的背景知识。
环境变量设置
可以通过 /etc/security/limits 文件对各用户的基本配置参数包括 core 大小进行限制。或者通过 ulimit 更改当前环境下的 core 大小限制。