core文件调试需确保可执行文件未被strip（file命令显示not stripped），并用gdb ./myapp /path/to/core-file加载；若core_pattern路径无写权限或core被systemd压缩，需先解压并验证权限；崩溃信号类型（如sigsegv/sigabrt）比堆栈更能精准定位根因。
确认core文件是否包含调试信息
生产环境的可执行文件经常被strip过，gdb加载后会提示 No symbol table is loaded，这时即使有core文件也几乎无法定位到源码行。必须确认二进制是否保留了调试符号：file ./myapp 输出中含 not stripped 才可靠；若显示 stripped，需回退到构建时未strip的版本，或用 objcopy --add-gnu-debuglink=debug-file myapp 补符号。
用gdb加载core并查看崩溃点
命令格式固定：gdb ./myapp /path/to/core-file。注意两点：可执行文件路径必须与崩溃时一致（尤其涉及RPATH或loader路径）；core文件不能被压缩（systemd默认用zstd压缩，得先用 zstd -d core.xxx.zst -o core.xxx 解压）。进入gdb后优先执行：
-
bt—— 查看完整调用栈，重点看最顶层的#0帧 -
info registers—— 检查rip/rsp是否异常（如rip == 0x0大概率是空函数指针调用） -
frame 0后接list—— 尝试显示崩溃点附近源码（仅当符号可用）
core_pattern路径不匹配导致找不到文件
很多线上服务以非root用户运行，而/proc/sys/kernel/core_pattern 若配置为 /var/core/core-%e-%p-%t，但该目录对普通用户不可写，结果core根本没生成——连ulimit -c unlimited 都无效。验证方法：cat /proc/sys/kernel/core_pattern 看路径，再用崩溃进程的uid执行 touch /var/core/test 测试权限。常见解法：
- 改用用户有写权限的路径，如
/tmp/core-%e-%p-%t - 用
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e交由systemd接管（需确保systemd-coredump已启用） - 容器场景下，必须挂载宿主机目录并显式设置
securityContext.allowPrivilegeEscalation: false外的cap_add: [SYS_PTRACE]
信号编号与崩溃原因强关联
core文件元数据里记录了触发信号，gdb 中用 info program 可看到类似 Program terminated with signal SIGSEGV, Segmentation fault.。不同信号指向完全不同的问题类型：
-
SIGSEGV (11)：90%以上是空指针、野指针、栈溢出或内存映射失败 -
SIGABRT (6)：常见于assert()失败、malloc内部检测到堆损坏、C++ 异常未捕获 -
SIGBUS (7)：结构体字段未对齐、mmap区域被意外unmap后访问 -
SIGFPE (8)：除零、整数溢出（尤其在优化开启时可能被编译器静默处理）
别只盯着bt输出——先看信号，它比堆栈更能缩小根因范围。
