linux core通常指的是Linux系统下的核心转储文件,是程序在运行过程中发生严重错误导致异常终止时,操作系统自动将程序当时的内存状态、寄存器信息、调用栈等数据保存到磁盘的文件,也常被称为core dump文件。

linux core的生成触发场景
并不是所有程序终止都会生成linux core文件,只有当程序收到特定的终止信号时才会触发生成,常见的触发信号包括:
- SIGSEGV:程序访问了非法内存地址,比如空指针解引用、数组越界访问等
- SIGABRT:程序主动调用abort函数触发的终止信号
- SIGFPE:程序执行了错误的算术运算,比如除零操作
- SIGBUS:程序访问了不存在的物理内存地址
linux core的相关配置
默认情况下,很多Linux系统会限制core文件的大小为0,也就是不会生成core文件,我们可以通过以下方式调整配置。
查看当前core文件大小限制
使用ulimit命令可以查看当前的core文件大小限制:
# 查看core文件大小限制,0表示不生成core文件 ulimit -c
临时开启core文件生成
可以通过ulimit命令临时修改core文件大小限制:
# 设置为unlimited表示不限制core文件大小 ulimit -c unlimited
永久配置core文件生成
如果需要永久生效,可以修改/etc/security/limits.conf文件,添加以下配置:
# 所有用户都不限制core文件大小 * soft core unlimited * hard core unlimited
自定义core文件保存路径和命名规则
默认core文件会生成在程序运行的当前目录,文件名为core,我们可以通过修改/proc/sys/kernel/core_pattern文件自定义保存规则:
# 设置core文件保存到/var/core/目录,文件名格式为core-程序名-进程ID-时间戳 echo "/var/core/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
其中常见的命名占位符含义如下:
| 占位符 | 含义 |
|---|---|
| %e | 程序文件名 |
| %p | 进程ID |
| %t | 核心转储的时间戳 |
| %s | 触发core的信号编号 |
如何分析linux core文件
生成core文件后,我们需要使用调试工具来分析文件内容,定位程序崩溃的原因,最常用的工具是gdb。
准备调试环境
分析core文件需要保留程序崩溃时的可执行文件,并且最好是带有调试符号的版本,否则只能看到内存地址,无法对应到具体的代码行。
使用gdb分析core文件
假设可执行文件为test,core文件为core-test-1234-1690000000,分析命令如下:
# 启动gdb加载可执行文件和core文件 gdb ./test core-test-1234-1690000000
进入gdb交互界面后,常用的分析命令如下:
# 查看崩溃时的调用栈 bt # 查看崩溃位置附近的代码 list # 查看崩溃时的变量值 print 变量名 # 查看所有线程的状态 info threads # 切换到指定线程 thread 线程ID
简单示例演示core生成与分析
首先编写一个会触发段错误的C程序:
#include <stdio.h>
int main() {
int *p = NULL;
// 解引用空指针,触发SIGSEGV信号,生成core文件
*p = 10;
return 0;
}
编译程序时加上-g参数保留调试符号:
gcc -g test.c -o test
开启core生成后运行程序:
ulimit -c unlimited ./test
程序崩溃后会在当前目录生成core文件,使用gdb分析:
gdb ./test core # 进入gdb后执行bt命令,会看到调用栈指向*p = 10这一行,明确崩溃原因
linux core的常见使用注意事项
- core文件可能包含程序的内存敏感信息,比如密码、密钥等,生成后需要注意文件权限,避免敏感信息泄露
- 线上生产环境不建议长期开启不限制core文件大小,避免程序频繁崩溃生成大量大体积core文件占满磁盘空间
- 如果是容器环境,需要额外配置容器的core文件挂载路径,否则core文件可能生成在容器内部,难以获取分析
linux_corecore_dump信号调试工具修改时间:2026-06-11 05:09:29