如何保存并分析Linux内核转储(coredump)文件

简介: 在Linux中,生成coredump需配置系统参数并满足程序条件。通过ulimit或limits.conf设置核心文件大小,修改core_pattern定义存储路径与命名格式,确保程序无信号屏蔽、权限限制,并留足磁盘空间,最后用gdb分析崩溃堆栈,便于调试定位问题。

在 Linux 系统中,保存用户程序的 coredump 文件(核心转储文件)需要配置系统参数确保程序满足生成条件,以下是完整配置与使用方法。

一、核心概念

coredump 是程序崩溃时,系统将其内存、寄存器、堆栈等状态保存到的文件,用于事后调试(如用 gdb 分析崩溃原因)。
默认情况下,Linux 可能会限制 coredump 的生成(如大小限制为 0)。

二、修改系统 coredump 配置

1. 临时配置(重启后失效)

通过 ulimit 命令修改当前会话的资源限制:

# 查看当前 coredump 大小限制(默认可能为 0,即禁止生成)
ulimit -c

# 设置 coredump 大小无限制
ulimit -c unlimited

# 或设置固定大小(单位:块,1块=512字节),例如 100MB
ulimit -c $((100 * 1024 * 1024 / 512))

2. 永久配置(重启后生效)

修改 /etc/security/limits.conf 文件,对指定用户或所有用户生效:

sudo vim /etc/security/limits.conf

添加以下内容:

# 对所有用户生效(* 表示所有用户)
*               soft    core            unlimited
*               hard    core            unlimited

# 或仅对特定用户生效(如 user1)
user1           soft    core            unlimited
user1           hard    core            unlimited
  • soft:软限制,用户可自行临时突破
  • hard:硬限制,系统强制的最大限制

生效方式

  • 普通用户需重新登录
  • 系统服务需重启对应服务

3. 配置 coredump 文件的命名与存储路径

默认情况下,coredump 文件会生成在程序的当前工作目录,文件名是 core
如需自定义文件名和路径(推荐),修改 /proc/sys/kernel/core_pattern

# 查看当前配置
cat /proc/sys/kernel/core_pattern

# 临时修改(重启后失效):格式说明见下文
sudo sysctl -w kernel.core_pattern=/var/crash/core-%e-%p-%t

# 永久修改:编辑 /etc/sysctl.conf
sudo vim /etc/sysctl.conf
# 添加以下行
kernel.core_pattern=/var/crash/core-%e-%p-%t
# 生效配置
sudo sysctl -p

core_pattern 格式参数说明
| 参数 | 含义 |
|------|------|
| %e | 程序名称 |
| %p | 程序 PID |
| %t | 转储时间戳(秒) |
| %u | 程序所属 UID |
| %g | 程序所属 GID |
| %h | 主机名 |

注意:确保存储目录存在且可写:

sudo mkdir -p /var/crash
sudo chmod 777 /var/crash  # 临时测试,生产环境建议限制权限

三、确保程序满足生成 coredump 的条件

  1. 程序未被设置 setuid/setgid 且非特权程序
    若程序有 setuid 权限(如 sudo 运行的程序),需额外配置 /proc/sys/fs/suid_dumpable

    # 临时允许 suid 程序生成 coredump
    sudo sysctl -w fs.suid_dumpable=2
    # 永久配置:添加到 /etc/sysctl.conf
    fs.suid_dumpable=2
    sudo sysctl -p
    
    • 0:禁止 suid 程序生成 coredump(默认)
    • 1:生成的 coredump 仅对 root 可见
    • 2:生成的 coredump 对程序所属用户可见
  2. 程序未被信号屏蔽
    程序若通过 signal(SIGSEGV, SIG_IGN) 等方式屏蔽了崩溃信号(如 SIGSEGV),则不会生成 coredump

  3. 文件系统有足够空间
    确保 coredump 存储目录所在分区有足够空间,避免因空间不足导致生成失败。

四、步骤 3:测试 coredump 生成

编写一个会崩溃的测试程序 crash.c

#include <stdio.h>

int main() {
   
    // 空指针解引用,触发 SIGSEGV 崩溃
    int *p = NULL;
    *p = 10;
    return 0;
}

编译并运行:

# 编译时保留调试信息(必须加 -g,否则 gdb 无法调试)
gcc -g crash.c -o crash

# 运行程序,触发崩溃
./crash

此时会在 /var/crash 目录下生成类似 core-crash-12345-1735689000 的文件。

五、使用 gdb 分析 coredump 文件

# 格式:gdb 程序可执行文件 coredump 文件
gdb ./crash /var/crash/core-crash-12345-1735689000

gdb 中输入 bt 命令,即可查看崩溃时的调用堆栈:

(gdb) bt
#0  0x0000555555555145 in main () at crash.c:6
相关文章
|
NoSQL 安全 Linux
Linux 中 core dump 文件的作用和使用方法
Linux 中 core dump 文件的作用和使用方法
3247 1
|
编解码 Java 编译器
【Protobuf】Protobuf中的Message语法规范
在Message中定义一个或者多个字段,FieldType是字段的数据类型,可以是基本类型(如int32、string、bool等)或其他定义的Message类型。fieldName是字段的名称,可以根据需求自定义。fieldNumber是字段的唯一标识号,用于在消息的二进制编码中标识字段。
1391 0
|
存储 NoSQL Unix
【Core dump】关于core的相关配置:关于核心转储文件core dump的显示和设置位置
【Core dump】关于core的相关配置:关于核心转储文件core dump的显示和设置位置
1931 11
|
存储 网络协议 C语言
一文带你秒懂 字节序(byte order),比特序(bit order),位域(bit field)
一文带你秒懂 字节序(byte order),比特序(bit order),位域(bit field)
2033 0
|
存储 Linux C++
CMake深度解析:掌握add_custom_command,精通Makefile生成规则(二)
CMake深度解析:掌握add_custom_command,精通Makefile生成规则
846 0
|
安全 Linux 开发工具
【Azure 环境】Azure 虚拟机上部署 DeepSeek R1 模型教程(1.5B参数)【失败】
遇见错误一:operator torchvision::nms does not exist 遇见错误二:RuntimeError: Failed to infer device type
1409 22
|
运维 NoSQL Ubuntu
深入理解Linux中的"crash"命令:内核崩溃的调试利器
`crash`是Linux内核崩溃调试工具,用于分析内核崩溃转储文件,提供GDB-like的交互式CLI。通过加载`vmcore`文件和内核映像,管理员可以查看系统状态、调用栈、内存布局等。安装`crash`可使用包管理器,如`apt-get`或`yum/dnf`。尽管有学习曲线且依赖转储文件,但`crash`在系统故障排查中极其重要。
|
存储 安全 Linux
调整 core dump 的存储位置或限制
【10月更文挑战第1天】
1921 2
|
存储 NoSQL Linux
linux之core文件如何查看和调试
通过设置和生成 core 文件,可以在程序崩溃时获取详细的调试信息。结合 GDB 等调试工具,可以深入分析 core 文件,找到程序崩溃的具体原因,并进行相应的修复。掌握这些调试技巧,对于提高程序的稳定性和可靠性具有重要意义。
8330 6