GDB跟踪core

如果程序崩了，怎么进行错误的定位？

主要有两种方式：

1. 查看日志定位，程序出错在哪里；
2. 程序自身产生的coredump文件一般可以用来分析程序运行到哪里出错了。

1.核心转储

核心文件（core file），也称磁芯倾印（core dump），是操作系统在进程收到某些信号而终止运行时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件。这种信息往往用于调试。（来自wiki）

2.设置coredump文件的生成

我采用的Linux 16.04，打开终端：

• 查看core文件的大小，输入：ulimit -a，可以看到大小为0，则默认不会生成core dump文件。
• 
• 在终端中输入命令 ulimit -c ，输出的结果为 0，说明默认是关闭 core dump 的，即当程序异常终止时，也不会生成 core dump 文件。
• sudo vim /etc/security/limits.conf ，打开 /etc/security/limits.conf文件，取消这一行注释，修改为下图：
• 
• 修改 core 文件保存的路径
  • 默认生成的 core 文件保存在可执行文件所在的目录下，文件名就为 core。
  • 修改 /proc/sys/kernel/core_uses_pid 文件可以让生成 core 文件名自动加上 pid 号。
    例如 sudo echo 1 > /proc/sys/kernel/core_uses_pid ，生成的 core 文件名将会变成 core.pid，其中 pid 表示该进程的 PID。
  • 修改 /proc/sys/kernel/core_pattern 来控制生成 core 文件保存的位置以及文件名格式。
    例如可以用 sudo echo "/tmp/corefile-%e-%p-%t" > /proc/sys/kernel/core_pattern 设置生成的 core 文件保存在 “/tmp/” 目录下，文件名格式为 “core-命令名-pid-时间戳”。

3.GDB调试core文件

coredump.c

#include 

int main(int argc, char *argv[])
{
	int *null_ptr=NULL;
	*null_ptr = 10;
	return 0;
}

• 编译指令：gcc coredump.c -o coredump -g

• 执行./coredump程序：
  

• 然后用gdb调试core文件：

lzj@ubuntu:~/Desktop/linux$ gdb coredump /tmp/corefile-coredump-86646-1595770840
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
...
Core was generated by `./coredump'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000004004ed in main (argc=1, argv=0x7fff24bc5818) at coredump.c:6
6		*null_ptr = 10;
(gdb) where 
#0  0x00000000004004ed in main (argc=1, argv=0x7fff24bc5818) at coredump.c:6 
(gdb) info frame
Stack level 0, frame at 0x7fff24bc5740:
 rip = 0x4004ed in main (coredump.c:6); saved rip = 0x7f5ea8cb2840
 source language c.
 Arglist at 0x7fff24bc5730, args: argc=1, argv=0x7fff24bc5818
 Locals at 0x7fff24bc5730, Previous frame's sp is 0x7fff24bc5740
 Saved registers:
  rbp at 0x7fff24bc5730, rip at 0x7fff24bc5738
(gdb) q
lzj@ubuntu:~/Desktop/linux$ 

从上面可以看出，我们可以还原 coredump 执行时的场景,并使用 where 可以查看当前程序调用函数栈帧，还可以使用 gdb 中的命令info frame查看寄存器，变量等信息，最后q退出gdb调试。

４.参考

https://www.cnblogs.com/hazir/p/linxu_core_dump.html

https://www.cnblogs.com/dongzhiquan/archive/2012/01/20/2328355.html