linux下coredump的产生及调试方法

什么是coredump

一般状况下coredmp包括了程序执行时的内存，寄存器状态，堆栈指针，内存管理信息等。可以理解为把程序工做的当前状态存储成一个文件。不少程序和操做系统出错时会本身主动生成一个core文件。

怎样使用coredump

coredump可以用在很是多场合，使用Linux,或者solaris的人可能都有过这样的经历，系统在跑一些压力測试或者系统负载一大的话，系统就hang住了或者干脆system panic.这时惟一能帮助你分析和解决这个问题的就是coredump了。

现在很是多应该程序出错时也会出现coredump.

分析coredump的工具

现在大部分类unix操做系统都提供了分析core文件的工具，比方 GNU Binutils Binary File Descriptor library (BFD), GNU Debugger (gdb），mdb等

coredump的文件格式

类unix操做系统中使用efi格式保存coredump文件。

在solairs下

bash-3.2# file *unix.3 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information availableunix.4 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information available

形成程序coredump的缘由很是多，这里依据以往的经验总结一下：

1 内存訪问越界
  a) 由于使用错误的下标，致使数组訪问越界
  b) 搜索字符串时，依靠字符串结束符来推断字符串是否结束，但是字符串没有正常的使用结束符
  c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操做函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

2 多线程程序使用了线程不安全的函数。
应该使用如下这些可重入的函数，尤为注意红色标示出来的函数，它们很是easy被用错：
asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n) ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c) getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c) fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c) getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3) getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n) nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3) getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c) getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c) getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)

3 多线程读写的数据未加锁保护。
对于会被多个线程同一时候訪问的全局数据，应该注意加锁保护，不然很是easy形成core dump

4 非法指针
  a) 使用空指针
  b) 任意使用指针转换。一个指向一段内存的指针，除非肯定这段内存原先就分配为某种结构或类型，或者这样的结构或类型的数组，不然不要将它转换为这样的结构或类型 的指针，而应该将这段内存复制到一个这样的结构或类型中，再訪问这个结构或类型。这是因为假设这段内存的開始地址不是依照这样的结构或类型对齐的，那么訪问它 时就很是easy因为bus error而core dump.

5 堆栈溢出
不要使用大的局部变量（因为局部变量都分配在栈上），这样easy形成堆栈溢出，破坏系统的栈和堆结构，致使出现莫名其妙的错误。

coredump文件的生成方法以及用法：

（若是下例是在x86上交叉编译，而在arm上执行异常的现象）

1． 在arm内核里添�coredump的支持（通常内核都支持coredump, 不用重编）

2． 执行命令，此时赞成coredump文件产生：(在arm上)
ulimit –c unlimited

3． 运行程序：（在arm上）
./test
在异常退出时，会显演示样例如如下信息，注意括号中的内容
Segmentation fault (core dumped)
程序运行文件夹下将产生*core文件

4． 用gdb分析：（在x86上）
arm-linux-gdb ./test test.core
再用gdb的bt或where看就可以了
(arm-linux-gdb的编译见<调试工具之四gdbserve>)

系统支持生成core并设置存储位置的方法：

1> 在/etc/profile中添�下面一行，这将赞成生成coredump文件 ulimit -c unlimited 2> 在rc.local中添�下面一行，这将使程序崩溃时生成的coredump文件位于/tmp文件夹下: echo /tmp/core.%e.%p > /proc/sys/kernel/core_pattern  /tmp/也可以是其余的文件夹位置。最佳位置应当知足下面需求： * 对所有用户可写 * 空间容量足够大 * 掉电后文件不丢失