目录
一、概述
在 UNIX 系统中,常将“主内存称为核心(core),因为在使用半导体作为内存材料之前,便是使用核心(core)。而核心映像(core image)就是 “进程”(process)执行当时的内存内容。当进程发生错误或收到 “信号”(signal)而终止执行时,系统会将核心映像写入一个文件,以作为调试之用,这就是所谓的核心转储(core dump)。
Core dump
是指在程序异常终止时,操作系统将程序的内存映像保存到磁盘上的一种机制。
在 Linux 系统中,core dump
提供了一种调试程序错误的重要方式,它记录了程序在崩溃时的内存状态,可以帮助开发人员快速定位问题。当程序因为某种原因(如段错误、非法指令等)异常终止时,Linux 系统会尝试将程序在内存中的映像、程序计数器、寄存器状态等信息写入到一个名为 core 的文件中,这个文件就是所谓的 core dump
。
以下是一些常见的导致 core dump
的错误:
- 段错误(Segmentation fault)
- 程序访问了无效的内存地址,比如试图访问未分配的内存或者已经释放的内存
- 空指针引用(Null pointer dereference)
- 程序试图使用空指针访问内存中的数据时,会导致空指针引用错误
- 内存访问越界(Out of bounds memory access)
- 程序试图访问数组或者其他数据结构超出其边界范围的内存,就会发生内存访问越界错误
- 使用已释放的内存(Use after free)
- 程序试图在已经释放的内存地址上进行读取或写入操作时,就会发生使用已释放的内存错误
- 栈溢出(Stack overflow)
- 程序递归调用层数过深或者在栈上分配了过多的内存时,会导致栈溢出错误
- 除以零(Division by zero)
- 无效的指令或操作码(Invalid instruction or opcode)
- 执行了不存在或无效的机器指令或操作码,会导致无效指令错误
- 硬件故障或操作系统错误:如内存损坏、内核崩溃等情况
二、发生 core dump 的原因
在 Linux 中,发生 core dump
是因为程序发生了严重错误,导致程序被强制终止。当程序遇到一个无法处理的错误时,操作系统为了进行调试和分析,会将程序的内存空间中的所有数据,包括堆栈和堆的内容等,以一种特殊的文件格式保存到一个称为 core dump
的文件中。
当程序发生 core dump
时,可以使用调试工具(如 gdb)来分析 core dump
文件,找出导致程序崩溃的具体原因。调试工具可以提供堆栈跟踪、变量值查看等功能,帮助我们定位和解决问题。
1. 空指针或非法指针
空指针或非法指针(野指针、悬空指针)引起 core dump
是一种最常见的核心转储,大致可以有 3 种原因导致程序出现异常:
- 对空指针进行解引用等操作;
- 声明指针变量后未进行初始化,并直接进行操作,极大概率引发
core dump
,此类未经初始化的指针,统称野指针; - 对某个指针,调用了 free 函数或者 delet 函数,该指针指向的空间已经被释放,但未将该指针重新指向 NULL,此类指针成为悬空指针。对悬空指针再次操作,也会引发
core dump
。
2. 数组越界或指针越界
- 数组越界:当程序访问数组中超出其有效索引范围的元素时,会发生数组越界错误。例如,如果一个数组有 5 个元素,但程序尝试访问第 6 个元素,就会导致越界错误。
- 指针越界:当程序使用指针来访问无效的内存地址时,会发生指针越界错误。例如,如果一个指针指向了一个已经释放或未分配的内存区域,或者指针超出了其有效范围,就会导致指针越界错误。
3. 数据竞争
数据竞争是指多个线程同时访问共享的数据,并且至少一个线程试图对该数据进行写操作。当发生数据竞争时,由于缺乏同步机制,可能会导致未定义行为,其中包括 core dump
。
数据竞争可能导致以下问题之一:
- 无效的内存访问:并发写入共享数据时,可能会导致内存损坏或非法内存访问,从而导致
core dump
。 - 竞争条件:当多个线程操作共享数据而没有正确的同步时,可能会导致竞争条件的出现。例如,线程 A 读取共享数据,线程 B 写入共享数据,并且线程 A 使用了未正确同步的数据,从而导致
core dump
。 - 死锁:当多个线程同时请求锁资源,并且循环等待对方释放锁资源时,就会发生死锁。这可能导致线程无法继续执行,最终导致
core dump
。
三、分析 core dump 的方法
1. 启用 core dump
默认情况下,程序运行崩溃导致 core dump
,是不会生成 core 文件的,因为系统的 RLIMIT_CORE
(核心文件大小)资源限制,默认情况下设置为 0。
先查看系統默认:ulimit -c
命令用于显示当前用户的 core dump
文件的大小限制。输出结果的含义如下:
- 数字(以 KB 为单位),表示当前用户允许生成的
core dump
文件的最大大小限制 - unlimited,表示当前用户允许生成任意大小的
core dump
文件 - 0,表示当前用户不允许生成
core dump
文件
通过以下命令可在用户进程触发信号时启用 core dump
生成,并使用合理的名称将核心文件位置设置为 /tmp/
。请注意,这些设置不会永久存储,重启或者重新登录就会失效。
$ ulimit -c unlimited
$ echo 1 | sudo tee /proc/sys/kernel/core_uses_pid
$ echo "/tmp/core-%e-%s-%u-%g-%p-%t" | sudo tee /proc/sys/kernel/core_pattern
使 core 文件名称是否带有 pid,配置文件 /proc/sys/kernel/core_uses_pid
的内容为 1,添加 pid;0为不添加 pid;
下面是 /tmp/core-%e-%s-%u-%g-%p-%t
的各个参数的含义:
• %e:导致 core dump 的程序的可执行文件名。
• %s:导致 core dump 的信号编号。
• %u:导致 core dump 的程序的实际用户 ID。
• %g:导致 core dump 的程序的实际组 ID。
• %p:导致 core dump 的程序的进程 ID。
• %t:core dump 发生时的时间戳(自 epoch 时间以来的秒数)。
因此,/tmp/core-%e-%s-%u-%g-%p-%t
会生成包含如下信息的 core 文件:
/tmp/core-<executable>-<signal>-<uid>-<gid>-<pid>-<timestamp>
要想永久开启 core dump
功能,需要修改配置文件 /etc/security/limits.conf
,修改如下:
$ more /etc/security/limits.conf
* soft core unlimited
## 要关闭修改如下: * soft core 0
登出重新连接即可生效
通过如下命令可以查看详细显示信息:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15135
max locked memory (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15135
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
2. 触发 core dump
下面使用两个简单的 C 程序作为示例。
2.1 因空指针解引用而崩溃
文件名为 test.c:
#include <stdio.h>
int main() {
int *ptr = NULL; // 声明一个空指针
// 尝试解引用空指针
printf("尝试解引用空指针...\n");
printf("空指针的值为:%d\n", *ptr); // 这里会引发未定义行为
return 0;
}
编译并运行程序:
$ gcc -g -o test test.c
$ ./test
运行程序后,会在 /tmp/
文件夹下生成一个 core 文件。
2.2 通过 信号触发 core dump
core dump
文件一般是在收到某个信号的时候结束产生,如果不指定特定的信号,应用程序按默认方式处理,默认处理的信号如下:
3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS
8) SIGFPE 11) SIGSEGV 31) SIGSYS 24) SIGXCPU 25) SIGXFSZ 29) SIGIO
此例通过 SIGSEGV 信号触发 core dump,文件名为 test2.c:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
while (1)
sleep(1);
return 0;
}
编译并运行程序:
$ gcc -g -o test2 test2.c
$ ./test2
然后再打开一个终端,杀死这段进程:
这是,就会在 /tmp/
文件夹下生成一个 core 文件。
3. 利用 gdb 分析 core dump
两个例子都是段错误导致的 core dump
,所以用 gdb 调试的方法也是一样的,命令格式如下:
$ gdb <program_name> <core_dump_file>
比如先调试第一个例子的 core 文件,则输入如下命令:
$ gdb test /tmp/core-test-11-1000-1000-11695-1722948057
可以看到 gdb 提示在代码的第 8 行出错了:
如果函数关系调用关系很复杂,可以用
bt
命令(backtrace)查看调用堆栈(where
命令也有同样功能),如下图可知是在调用 main 函数时产生的段错误,可用 list
命令查看,具体就是 list
加函数名,如下图。然后通过 p
(print) 命令,打印出 ptr 的值,可以发现 ptr 指针是一个空指针:
或者可以通过查看汇编代码来排查问题:
通过 disass
命令可以打印出出现错误的代码段:
再通过 info reg
(info registers
) 查看各个寄存器的值:
可以看到寄存器 rax 的地址为 0,说明这个指针 ptr 是个空指针。
第二个例子,也是同样用 gdb 打开 core 文件:
gdb test2 /tmp/core-test2-11-1000-1000-11802-1722948499
虽然这个段错误是因为我们人为地发送了
SIGSEGV
信号,导致了程序地段错误,而在打开 core 文件后,可以看出在执行 __GI___clock_nanosleep
函数时,遇到了段错误。
通常情况下,分析
core dump
问题,除了 core 文件之外,还会结合程序的 log 信息和系统的 log 信息(包括kernel log
、systemd log
等)一起分析。
如果我们不事先知道是由 SIGSEGV
信号导致段错误的,首先要用 bt
命令找到函数的调用关系链:
前面三个函数是封装过的库函数,所以没办法看见具体实现:
在前面输入
bt
命令查看堆栈情况时,有出现了两个变量,分别是 req 和 rem。这个两个变量是 nanosleep
函数的形参,原型是 int nanosleep(const struct timespec *req, struct timespec *rem)
。
用 print
命令打印出两个变量的地址:
再使用 info registers
命令查看寄存器状态,检查程序在崩溃时的上下文:
从寄存器状态来看,没有明显的错误迹象,函数的栈帧空间没什么问题,形参的位置和值也没什么问题,所有值看起来都在正常范围内。
当下是没办法直接了当的判断为人为干预造成 core dump
,如果此时想到了信号会引发段错误,可以用 info signals
命令查看信号情况:
从 info signals
的输出中可以看出,SIGSEGV(Segmentation fault)信号是设置为在程序接收到该信号时停止执行并打印信息的。也就说,可以人为地使用 kill -11
发送了 SIGSEGV 信号来终止程序并生成 core dump
。