如果程序崩了,怎么进行错误的定位?
主要有两种方式:
- 查看日志定位,程序出错在哪里;
- 程序自身产生的coredump文件一般可以用来分析程序运行到哪里出错了。
核心文件(core file),也称磁芯倾印(core dump),是操作系统在进程收到某些信号而终止运行时,将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件。这种信息往往用于调试。(来自wiki)
我采用的Linux 16.04
,打开终端:
ulimit -a
,可以看到大小为0,则默认不会生成core dump
文件。ulimit -c
,输出的结果为 0,说明默认是关闭 core dump
的,即当程序异常终止时,也不会生成 core dump
文件。sudo vim /etc/security/limits.conf
,打开 /etc/security/limits.conf
文件,取消这一行注释,修改为下图: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-时间戳”。coredump.c
#include
int main(int argc, char *argv[])
{
int *null_ptr=NULL;
*null_ptr = 10;
return 0;
}
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