Core Dumps 是一个用于生产环境崩溃事后调查的技能，目标是在不重新运行那个已经崩溃的程序的前提下，引导代理完成 core dump 的启用、采集与分析。
用途
该技能用于指导在 Linux 与 macOS 上启用和采集 core dump，并使用调试器进行 post-mortem 崩溃分析。它明确覆盖以下触发场景：程序在生产环境崩溃后如何分析 core；“如何在 Linux 上启用 core dump”；“有 core 文件但没有符号或源码”；“如何用 debuginfod 为 core 获取符号”；“coredumpctl 展示崩溃信息”。
主要能力与工作流
1. 在 Linux 上启用 core dump
- 按会话启用：
ulimit -c unlimited（登出后失效） - 持久化配置（写入 /etc/security/limits.conf）：
* soft core unlimited* hard core unlimited - 检查当前限制：
ulimit -c - 设置 core 命名模式（默认在当前工作目录生成名为 core 的文件，通常不实用）：
sudo sysctl -w kernel.core_pattern=/tmp/core-%e-%p-%t其中 %e 为可执行文件名、%p 为 PID、%t 为时间戳。 - 持久化（写入 /etc/sysctl.d/99-core.conf）：
kernel.core_pattern=/tmp/core-%e-%p-%tkernel.core_uses_pid=1
2. systemd / coredumpctl（现代 Linux） 当 systemd 管理 core dump 时（常见于 Ubuntu 20+、Fedora、Arch）：
coredumpctl list列出近期崩溃coredumpctl info查看最近一次崩溃详情coredumpctl gdb在 GDB 中加载最近一次崩溃coredumpctl gdb 12345加载指定 PID 的崩溃coredumpctl dump -o myapp.core PID导出 core 文件- core 存储位置：/var/lib/systemd/coredump/。
3. 在 macOS 上启用 core dump
- macOS 默认使用 /cores 目录（需要 root 可写）
ulimit -c unlimited- 检查：
ls /cores/ - 由 launchd 启动的服务需在 plist 中设置：
<key>HardResourceLimits</key><dict><key>Core</key><integer>9223372036854775807</integer></dict>
4. 使用 GDB 分析 core
- 加载二进制与 core：
gdb ./prog core.12345 - 若二进制被 strip，提供未 strip 的副本：
gdb ./prog-with-symbols core.12345 - 常用首批命令：
bt（调用栈）、bt full（栈与局部变量）、info registers（崩溃时的 CPU 状态）、frame 2（切换到关注的栈帧）、info locals（当前帧局部变量）、print ptr（查看指针） - 多线程崩溃查看所有线程：
thread apply all bt full
5. 使用 LLDB 分析 core
lldb ./prog -c core.12345，或进入 lldb 后target create ./prog --core core.12345- 命令：
bt、thread backtrace all、frame select 2、frame variable
6. 符号缺失：debuginfod debuginfod 从中央服务器提供调试符号，将 build ID 映射到 DWARF 数据。
- 安装客户端（Debian/Ubuntu）：
sudo apt install debuginfod - 启用（写入 ~/.bashrc 或 /etc/environment）：
export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com https://debuginfod.elfutils.org" - 设置 DEBUGINFOD_URLS 后，GDB 会自动拉取符号：
gdb ./prog core - 手动查询：
debuginfod-find debuginfo <build-id>、debuginfod-find source <build-id> /path/to/file.c
7. 符号缺失：手动方式
- 检查二进制是否含 build ID：
readelf -n ./prog | grep Build - 查找对应调试包：Debian 用
apt install prog-dbg或prog-dbgsym；RPM 用dnf install prog-debuginfo - 指定 GDB 调试符号目录：
(gdb) set debug-file-directory /usr/lib/debug - 也可用 eu-readelf 导出 build ID 后查找 .debug 文件：
eu-readelf -n ./progfind /usr/lib/debug -name "*.debug" | xargs eu-readelf -n 2>/dev/null | grep <build-id>
8. strip 二进制并保留符号 最佳实践是带符号构建、发布前 strip、并保留一份未 strip 的副本：
- 构建：
gcc -g -O2 -o prog main.c - 分离调试信息：
objcopy --only-keep-debug prog prog.debugobjcopy --strip-debug prog prog.stripped - 添加 debuglink 使 GDB 自动找到调试文件：
objcopy --add-gnu-debuglink=prog.debug prog.stripped - 部署 prog.stripped，将 prog.debug 保留在按 build ID 索引的符号库中。
9. 无需完整调试会话的快速分诊
- 非交互式打印回溯：
gdb -batch -ex 'bt full' -ex 'thread apply all bt full' ./prog core 2>&1 | tee crash.txt - 打印寄存器：
gdb -batch -ex 'info registers' ./prog core - 查看导致崩溃的信号：
gdb -batch -ex 'info signal' ./prog core
该技能指出，覆盖 core pattern 标记、coredumpctl、GDB/LLDB 命令、debuginfod 服务器以及 strip/符号工作流的完整速查表见 references/cheatsheet.md。
相关技能
- skills/debuggers/gdb：完整的 GDB 会话细节
- skills/debuggers/lldb：基于 LLDB 的分析
- skills/runtimes/sanitizers：在 bug 进入生产环境前捕获它
- skills/binaries/elf-inspection：readelf、build ID 与二进制检查
限制
技能文本未提供关于其自身安装方式、许可、价格或平台兼容性范围之外的更多信息，这些内容暂未提供。