在嵌入式的开发和测试中,有时候一些问题只能在特定的环境下才能重现,重现的时机和条件都难以把握,可能很多次的测试才能偶尔的重现一次问题,这给我们的调试和修改都带来很多不便之处
还有一种难以跟踪调试的情形,在大型的软件项目中,要从数万行甚至更多的代码中准确的找到问题所在,靠设断点和单步跟踪的方法是很麻烦很需要时间的.
这些问题可以通过Core Dump的方式,或者说事后调试(postmortem debug)技术,来协助分析.主要方法是在程序崩溃的时候,将程序的内存映象加上调试信息保存到一个文件中,这后通过分析这个所谓的Core文件来找到程序崩溃的原因.Core Dump的名称来源于以前工业界的叫法---当内存还是线圈的时候,它被叫做Core,我们可以利用GDB来分析core文件来查找出错的原因.
| Back in the day, a computer's main memory was built out of ferrite core. This is where the phrase "core dump" comes from: the main memory image of a program stored in a file on disk for diagnosis |
1. core文件的简单介绍
在一个程序崩溃时，它一般会在指定目录下生成一个core文件。core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。
2. 开启或关闭core文件的生成
用以下命令来阻止系统生成core文件:
ulimit -c 0
下面的命令可以检查生成core文件的选项是否打开:
ulimit -a
该命令将显示所有的用户定制，其中选项-a代表“all”。
也可以修改系统文件来调整core选项
在/etc/profile通常会有这样一句话来禁止产生core文件，通常这种设置是合理的:
# No core files by default
ulimit -S -c 0 > /dev/null 2>&1
但是在开发过程中有时为了调试问题，还是需要在特定的用户环境下打开core文件产生的设置
在用户的~/.bash_profile里加上ulimit -c unlimited来让特定的用户可以产生core文件
如果ulimit -c 0 则也是禁止产生core文件，而ulimit -c 1024则限制产生的core文件的大小不能超过1024kb
3. 设置Core Dump的核心转储文件目录和命名规则
/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0
/proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名，比如原来文件内容是core-%e
可以这样修改:
echo "/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
将会控制所产生的core文件会存放到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加当前uid
%g - insert current gid into filename 添加当前gid
%s - insert signal that caused the coredump into the filename 添加导致产生core的信号
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加命令名
4. 使用core文件
在core文件所在目录下键入:
gdb -c core
它会启动GNU的调试器，来调试core文件，并且会显示生成此core文件的程序名，中止此程序的信号等等
如果你已经知道是由什么程序生成此core文件的，比如MyServer崩溃了生成core.12345，那么用此指令调试:
gdb -c core MyServer
以下怎么办就该去学习gdb的使用了
5. 一个小方法来测试产生core文件
直接输入指令:
kill -s SIGSEGV $$ （杀掉当前shell）
【详细说明】
当程序因为未知原因down掉后，可以使用core dump把内存dump出来，用来调试时使用。
看一下core dump是否开启
#ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
看到core file size是0，说明core dump没开启，使用ulimit -c unlimited来开启core dump，当然unlimited也可以换成具体的文件大小（单位是kb），只是unlimited最省事儿
设置core dump文件名及其位置
查看core dump
gdb --core=core.12345(core dump文件名) 或 gdb exe名 core名
bt 查看程序运行到哪儿，backtrace
file exe名 找exe位置
l 列出代码
where 显示在哪儿down掉
注意：有些情况下，使用了seteuid或setegid，改变了进城了用户和组，比如，无论谁运行mysql，mysql都以mysql用户运行。这种情况下，默认系统不会做core dump，需要把/proc/sys/fs/suid_dumpable内容改成1来要求系统生成core dump