core文件是定位Linux进程崩溃的关键，保存内存镜像、寄存器状态和调用栈，需配置ulimit、core_pattern并用gdb配合可执行文件调试，常见原因包括空指针、内存越界、未对齐访问等。
Linux进程异常退出时生成的 core 文件 是定位崩溃原因的关键线索。它保存了进程终止瞬间的内存镜像、寄存器状态、调用栈等信息，配合调试器（如 gdb）可精准还原崩溃现场。但默认情况下系统可能禁用 core dump，或生成路径、大小受限，需手动配置才能有效捕获和分析。
确认 core 文件是否生成及位置
进程崩溃后未看到 core 文件，常见原因有三：系统禁止生成、权限不足、路径不可写。可通过以下方式排查：
- 执行
ulimit -c查看当前 shell 的 core 文件大小限制，0 表示禁用；临时启用可运行ulimit -c unlimited - 检查
/proc/sys/kernel/core_pattern，它决定 core 文件名和保存位置。例如值为/var/core/core.%e.%p，表示生成在/var/core/下，文件名含程序名（%e）和 PID（%p） - 确保目标目录存在、属主可写，且磁盘空间充足；若
core_pattern以管道开头（如|/usr/lib/systemd/systemd-coredump），说明系统启用了 systemd-coredump 服务，需用coredumpctl查看
用 gdb 加载 core 文件调试
拿到 core 文件后，需搭配对应版本的原始可执行文件（带调试符号更佳）启动 gdb：
- 基本命令：
gdb ./myapp core.myapp.12345（假设可执行文件为myapp，core 文件名为core.myapp.12345） - 进入 gdb 后，输入
bt（backtrace）查看崩溃时的完整函数调用栈；info registers查看寄存器值；list显示崩溃点附近源码（需有调试信息） - 若提示
No symbol table is loaded，说明可执行文件未编译调试信息，应使用gcc -g重新编译；若符号在独立 debuginfo 包中（如 CentOS 的debuginfo-install），需先安装并用set debug-file-directory指定路径
常见崩溃原因与线索识别
通过栈回溯和寄存器状态，可快速聚焦典型问题：
-
段错误（SIGSEGV）：通常因空指针解引用、野指针访问、栈溢出或内存越界导致；
bt中若顶层是memcpy、strcpy或自定义函数中的数组操作，重点检查参数有效性 - 总线错误（SIGBUS）：多由未对齐内存访问（如 ARM 上强制按 4 字节读取非对齐地址）或 mmap 映射失败区域访问引发
-
浮点异常（SIGFPE）：除零、溢出或非法运算；栈中常出现
__kernel_vsyscall或数学库函数 - 若
bt显示大量??或无法解析符号，说明缺少调试信息或动态链接库不匹配；可用file core.xxx确认架构，readelf -l core.xxx | grep LOAD查看加载段是否完整
生产环境的实用建议
线上服务不宜直接开启 unlimited core dump，但也不能完全放弃诊断能力：
- 设置合理限制：如
echo "/var/log/core/core.%e.%p" > /proc/sys/kernel/core_pattern，并mkdir -p /var/log/core && chmod 1777 /var/log/core（sticky bit 防止用户删他人 core） - 结合
systemd-coredump：启用后自动压缩、按服务隔离、支持coredumpctl list --since="1 hour ago"快速筛选 - 对关键进程，可在启动前加
prctl(PR_SET_DUMPABLE, 1)确保即使 setuid 也能生成 core；或用echo 2 > /proc/sys/fs/suid_dumpable允许 setuid 程序 dump - 定期清理旧 core 文件，避免占满磁盘；可配合 logrotate 或定时脚本，按时间/大小轮转
