Linux下Breakpad崩溃捕获与minidump符号解析

凌晨两点被叫起来看一个跑在客户现场的采集进程挂掉，日志里只有一行Segmentation fault，没有栈、没有线程状态、没有当时的模块列表，唯一能确定的是"它死了"。后来我们把 core dump 打开、调大ulimit、盯着磁盘爆掉，再后来才把这套东西换成了 Breakpad。Breakpad 是业界用得最广的一套跨平台崩溃捕获与分析工具集，它在 Linux 上做的事情可以概括成三句话：在进程崩溃的瞬间把现场抓成一个小小的 minidump 文件，用编译产物里的调试信息生成符号文件，再用这两样东西把调用栈还原成人能读懂的文本。它解决的不是"程序为什么崩"这个业务问题，而是"崩溃时现场能不能留住"这个工程问题。下面这些内容适合三类人看：正在给 C/C++ 服务补崩溃监控的后端同学、维护客户端或边缘设备程序的嵌入式方向同学，以及第一次接触 minidump、被一堆0x0000卡住的运维与测试同学。我会从方案选型一路讲到符号目录结构和排查表格，命令和参数都是可以直接抄去跑的。

1. 崩溃现场这件事，先把方案选对

1.1 core dump 在线上环境的三个硬伤

系统自带的 core dump 是最省事的选择，ulimit -c unlimited一开，进程崩了内核就吐一个 core 文件出来。它在本地开发机上是神器，但搬到线上就会暴露三个很现实的毛病。第一个是体积。core 文件是进程地址空间的快照，一个常驻内存 2 GB 的服务，崩一次可能就是 2 GB 文件落盘，如果这个进程崩溃频率是每小时几次，磁盘和 IO 会先于业务被打死。第二个是可用性。很多线上环境出于安全考虑默认关掉了 core，或者把core_pattern交给系统级的服务接管，你未必能拿到文件；容器里更是如此，ulimit和内核参数是宿主机层面的东西，容器内的进程经常连一个字节都吐不出来。第三个是分析成本。core 文件是跟架构、内核、调试器版本强绑定的，你在开发机上用一套工具链未必能打开生产机器上生成的 core，而 core 又往往带着完整的内存内容，跨团队传一个几百兆的文件只为了看一个栈，沟通成本极高。

Breakpad 的思路是反过来的：它不追求把整个进程内存搬走，只抓"还原调用栈所必需的最小集合"。具体包括崩溃线程和各线程的寄存器上下文、各线程栈上的一段内存、已加载模块（可执行文件和动态库）的列表以及它们的标识、崩溃信号类型与崩溃地址。一个典型的 minidump 文件大小在几十 KB 到几 MB 之间，取决于线程数量和栈深度，压缩后往往只有几百 KB。这个体积意味着它可以被自动上报、可以被批量存储、可以在崩溃发生后的几秒钟内就到达分析端，而不是等着运维去机器上scp一个几十 G 的文件。代价是它不含堆内存，你没法在 minidump 里翻某个对象的字段值，想看堆上的东西还得回到 core dump。这个取舍在绝大多数场景下是划算的，因为九成以上的崩溃，看一眼调用栈就知道大概方向了。

1.2 Breakpad 的三段式模型：采集、符号、还原

Breakpad 用起来跟普通库不太一样，它不是一个"链接上就完事"的东西，而是一条三段式的流水线，任何一段断了，你拿到的都是一堆看不懂的十六进制。

第一段是采集端。你需要在目标程序里链接libbreakpad_client.a，在程序启动早期创建一个异常处理器对象，告诉它 minidump 往哪个目录写。这个对象会注册若干信号的处理函数，当进程收到段错误、总线错误、非法指令、除零、abort之类的信号时，它会在信号处理上下文里把现场写成一个.dmp文件，写完后再决定是让进程继续按原逻辑死掉，还是做点别的。

第二段是符号端。.dmp文件里存的是地址，是0x000055d4a1c2b3e0这种绝对值，没有任何函数名。要把它翻译成人话，你需要另一个文件：用dump_syms工具从带调试信息的可执行文件里提取出来的.sym文本文件。这个文件里记录了每个函数的起始地址、长度、源文件行号映射，以及一个非常关键的模块标识。

第三段是还原端。用minidump_stackwalk把.dmp和按特定目录结构摆放的.sym喂进去，它会输出一份文本报告，里面有崩溃信号、崩溃地址、每个线程的完整调用栈、每一帧的源文件名和行号。

三段的衔接靠的是一个叫模块标识（Module ID）的东西，采集端写进.dmp的模块标识，必须和dump_syms生成的.sym里的模块标识一字不差，否则还原端会告诉你"找不到符号"，然后给你一片???。这是新手踩坑最密集的地方，后面第 4 章会专门拆开讲。

1.3 什么情况下不该用 Breakpad

工具选型最怕的是"手里有锤子看什么都像钉子"。Breakpad 不适合的场景也很明确。

如果你的程序是短生命周期的命令行工具，跑完就退，崩溃了也没人管，那装 Breakpad 完全是浪费，直接看退出码和 stderr 更实在。如果你的程序崩溃后必须分析堆内存，比如排查内存踩踏、对象被释放后又被使用的悬垂指针问题，那 core dump 才是对的工具，minidump 帮不了你。如果你在的是一个已经有成熟崩溃收集体系的团队，那边可能已经在用更现代的方案，重复引入一套只会让符号管理变成两套。还有一种情况：你的程序在崩溃时内核会直接把整个进程干掉，连信号处理函数都跑不完，比如被SIGKILL杀掉或者发生栈溢出到无法在栈上执行任何代码，这种场景 Breakpad 也救不了，需要靠守护进程或者硬件看门狗。

另外提一句，Breakpad 在 Linux 上的实现是把写 dump 的逻辑放在信号处理上下文里同步执行的，这意味着它对"崩溃时进程状态有多烂"是有要求的。如果崩溃本身已经把堆或者锁搞坏了，写 dump 的过程中再次触发异常，那就什么都拿不到。这也是为什么现在有一些后续方案改成了"崩溃时 fork 一个干净的子进程去写"或者"用独立的守护进程通过管道接收现场"的思路。但这些方案的部署复杂度更高，对绝大多数业务来说，Breakpad 的直接写入模式已经足够稳。

2. 在 Linux 上把 Breakpad 编出来

2.1 环境与依赖确认

Breakpad 的源码是一堆 C++ 文件，没有预编译包，任何平台都得自己编。好消息是它的依赖极浅，不需要 boost、不需要 protobuf，主要是构建工具链。你需要准备：一个支持 C++11 的编译器（g++ 4.8 以上基本够用，建议 7 以上）、make、以及构建系统本身。如果你的源码版本用的是 autotools，那就还需要autoconf、automake、libtool、pkg-config；如果用的是 CMake 版本，那就需要 CMake 3.10 以上。

用常见的包管理器装依赖大致是这样：

# Debian/Ubuntu 系 sudo apt-get update sudo apt-get install -y build-essential cmake git \ autoconf automake libtool pkg-config # RHEL/CentOS 系 sudo yum groupinstall -y "Development Tools" sudo yum install -y cmake git autoconf automake libtool pkgconfig

注意：不要为了省事去装发行版仓库里的breakpad包。这类包通常只提供库而不提供dump_syms和minidump_stackwalk，或者版本极老、和你的编译器 ABI 对不上。自己编一次，产出的四个工具都在手上，后续排查问题时心里有底。

环境里还有两个容易被忽略的点。一是磁盘，Breakpad 的完整源码加编译中间产物大概要几百兆到 1 GB，如果你的构建机根分区很小，先确认一下空间。二是网络，源码托管在公共代码平台，如果构建机不能直连，那就提前在有网的环境里打好包再拷过去，注意把.git目录去掉能省不少体积。

2.2 CMake 与 autotools 两套构建方式

Breakpad 历史上用的是 autotools，近几年主线已经切到 CMake。你拿到源码后先看一眼根目录：如果有CMakeLists.txt，优先走 CMake；如果只有configure.ac，那就走 autotools。两套都能用，但 CMake 那套对新编译器更友好，编译报错少。

CMake 方式，推荐用独立的构建目录，别在源码目录里直接编：

cd breakpad cmake -S . -B build \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/opt/breakpad cmake --build build -j$(nproc)

autotools 方式，如果源码里没有configure脚本，先跑一遍./autogen.sh生成：

cd breakpad ./autogen.sh # 仅当没有 configure 时需要 ./configure --prefix=/opt/breakpad \ --disable-dependency-tracking make -j$(nproc)

几个 configure 选项值得知道。--disable-processor只编客户端库，如果你只想在目标机上采集、不在目标机上分析，用这个能显著缩短编译时间，产物也小。--disable-tools则相反，只编处理器和分析工具，适合那种"采集端在设备上、分析端在服务器上"的分离部署。--enable-selftest会编单元测试，需要额外拉测试框架，一般别开，编译时间翻倍还容易因为版本不匹配报错。

提示：如果你要在 32 位程序上采集，但构建机是 64 位的，需要给编译器和 CMake 都加上-m32（例如-DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32），并确保装了 32 位的基础运行库。dump_syms本身是可以解析 32 位 ELF 的，不需要单独编一份 32 位的分析工具。

2.3 四个关键产物和它们的用途

编完之后，你在构建目录里会找到四样真正重要的东西，其余的测试程序和示例都可以忽略。

minidump_dump这个工具很多人不知道，但它在排查"为什么解析不出符号"的时候极其有用。它不依赖任何符号文件，直接把 minidump 内部的模块列表、线程列表、内存区域全部打出来，你可以用它确认三件事：崩溃时到底加载了哪些模块、这些模块的标识是什么、崩溃线程的寄存器值是多少。当你发现minidump_stackwalk输出全是问号时，第一件事就该是拿minidump_dump看一眼模块标识，然后和.sym文件第一行对比。

另外还有两个冷门但偶尔救命的工具：minidump-2-core可以把 minidump 转回 core 文件，然后丢给常规调试器去看；core-2-minidump反过来，把你已有的 core 文件转成 minidump，这样历史遗留的 core 也能走 Breakpad 的分析链路。这两个工具在build/src/tools/linux/下，它们的存在意味着你不必在"core 派"和"minidump 派"之间二选一。

如果你想把这套工具装到一个统一前缀下方便多个项目共用：

cmake --install build # CMake 方式 # 或者 make install # autotools 方式

装完之后/opt/breakpad/include下是头文件，/opt/breakpad/lib下是客户端库，工具在/opt/breakpad/bin。记得把bin加进PATH，把lib加进链接器的搜索路径。

2.4 编译期最容易翻车的几处

第一类问题是头文件找不到。老版本的 Breakpad 在较新的编译器上会报'uint64_t' has not been declared、'size_t' has not been declared这类错误，原因是 GCC 13 之后对标准库头文件的间接包含做了收紧，以前靠别的头文件"顺带"引入的定义现在拿不到了。解决办法有两个：换用较新的 Breakpad 源码（主线已经修了），或者在你自己的构建里加编译选项-include cstdint -include cstddef强制预包含。我倾向于第一种，少打补丁。

第二类问题是链接阶段报undefined reference to 'dlopen'或者pthread_create。这是静态库的常见现象，静态库不会自动带上它依赖的系统库，你必须在链接命令的末尾手动补上-lpthread -ldl，顺序很重要，一定要放在libbreakpad_client.a之后，否则链接器不会回头去找。

第三类问题是 CMake 配置阶段报找不到某个可选依赖，然后构建直接中断。Breakpad 有些组件依赖 HTTP 客户端库（用于符号上传工具），如果你的环境里没有，配置会失败。这种情况加-DBREAKPAD_ENABLE_TOOLS=OFF或者干脆忽略那个工具，不影响核心的采集和解析功能。

第四类是内存不足。Breakpad 的处理器部分模板用得很多，-j$(nproc)在小内存机器上（比如 2 GB 的云主机）很容易 OOM，表现是编译器被内核杀掉、报internal compiler error: Killed。这种时候把并行度降到-j2就好，别怀疑代码有问题。

3. 把崩溃捕获接进自己的工程

3.1 最小可运行示例

先看一个能跑起来的最小版本，理解了三行代码的位置关系，再谈工程化。

#include <cstdio> #include <string> #include "client/linux/handler/exception_handler.h" #include "client/linux/handler/minidump_descriptor.h" static bool DumpCallback(const google_breakpad::MinidumpDescriptor& descriptor, void* context, bool succeeded) { if (succeeded) { fprintf(stderr, "[breakpad] minidump written: %s\n", descriptor.path()); } else { fprintf(stderr, "[breakpad] minidump failed\n"); } return succeeded; } int main(int argc, char** argv) { // 目录必须事先存在，Breakpad 不会帮你创建 google_breakpad::MinidumpDescriptor descriptor("/var/crash/myapp"); google_breakpad::ExceptionHandler handler( descriptor, nullptr, // filter：返回 false 可以拦下不写 DumpCallback, // 写完之后的回调 nullptr, // 传进回调的上下文 true, // install_handler：是否立刻安装信号处理 -1); // server_fd：进程外写入模式才用，这里不需要 int* p = nullptr; *p = 42; // 这里会触发 SIGSEGV return 0; }

编译链接命令大致长这样：

g++ -g -O2 -std=c++11 \ -I/opt/breakpad/src \ main.cpp \ -L/opt/breakpad/lib -lbreakpad_client \ -lpthread -ldl \ -o myapp

有两个细节必须说清楚。第一，-g不能省。你可能觉得"发布版本不需要调试信息，编个小体积的就行"，但dump_syms恰恰是从调试信息里提取函数名和行号的，没有.debug_info段，生成的.sym里会只有极少的符号甚至为空。正确做法是：带-g编译出完整产物，用它生成符号，然后再复制一份把调试信息剥掉用于发布。第二，-O2是可选的，但要知道优化等级会影响回溯质量。开启内联和尾调用优化后，有些栈帧会被合并或者消失，你看到的栈可能比源码里的调用层级"短"一截，这不是工具坏了，是编译器的功劳。

3.2 MinidumpDescriptor：落盘位置与命名

MinidumpDescriptor决定 dump 文件写到哪、叫什么名字。它有几种构造方式，用途不一样。

传一个目录，文件名为自动生成的 UUID，例如/var/crash/myapp/4f2a8c1e-9b3d-4a71-8c5e-2d1b0f7e6a93.dmp。这是最常用的方式，因为多进程、多次崩溃不会互相覆盖，事后按时间排序也方便。

传目录加文件名，适合"每次崩溃只保留一份、便于脚本监控"的场景，比如固定叫latest.dmp，你的守护脚本只要inotify这个文件就能立刻上报并清理，处理完再让程序起来。

还可以传一个已经打开的文件描述符，这是进程外写入模式的入口：父进程先创建管道或者打开文件，把 fd 交给 handler，崩溃时由另一个进程读取这个 fd 内容并落盘。这种方式的好处是写 dump 的动作完全脱离了崩溃进程的地址空间，稳定性最高。代价是实现复杂，还要处理管道阻塞的问题。

不管用哪种方式，有一个坑必须提前说：目录不存在时 Breakpad 不会创建，它会直接写失败，而且失败得相当安静，回调里的succeeded会是false，但你如果在回调里只是fprintf一句就返回，很容易忽略。所以初始化之前务必确认目录存在且可写：

install -d -m 0755 /var/crash/myapp

另外，跑在容器里的进程，落盘目录最好挂一个独立的emptyDir或tmpfs，别直接写容器根文件系统，否则一次崩溃把容器的可写层写满，会引发一连串莫名其妙的问题。

3.3 回调函数里能干什么

回调函数的设计初衷是"dump 写完了，你去做后续处理"。但这里有一个非常关键的认知：这个回调运行在信号处理上下文里，进程此时已经处于异常状态，栈可能已经被破坏，堆可能已经加了锁。

所以回调里能做的是极其有限的事情：记录一行日志到已经打开的 fd、把文件重命名、设置一个标志位、通知一个预先创建好的管道。绝对不能做的事情包括：调用malloc/new（可能死锁在堆锁上）、调用printf系列（内部可能加锁和分配缓冲）、发起网络请求、创建线程、等待其他线程的锁。我见过最典型的翻车案例是有人在回调里直接curl上传 dump，结果崩溃进程在信号上下文里卡死，变成了"进程不退出、也不产生 dump"的僵尸状态，运维只能手动kill -9，现场全丢。

正确做法是让回调只做"标记"这件事，真正的上传交给外部。比如把 dump 写到一个固定目录，回调里只是write()一个字节到预先创建的管道，守护进程或者另一个监控线程读到这个字节后去扫描目录、上传、清理。如果你确实需要在进程内做处理，至少把操作延后到信号上下文之外。

提示：还有一个filter回调，它在真正写 dump 之前被调用，返回false可以阻止这次 dump。它的用途是"按条件减少噪音"，比如某个已知的信号或者某个特定的崩溃地址每次都产生几百个重复文件，可以在 filter 里根据地址做一次简单判断。但同样不要在 filter 里做复杂操作，它比回调更早执行，此时现场更脆弱。

3.4 多线程、守护进程、子进程的现实问题

多线程程序是最常见的场景，这里有两个要点。一是 Breakpad 会 dump 所有线程的栈，不只是崩溃线程，这非常有价值——很多死锁型崩溃的真相就在另一个线程的栈上。二是线程数会直接影响 dump 文件大小和写入耗时，一个开了几百个线程的服务，每次崩溃写出的 minidump 可能要几 MB，写入时间也更长，如果在信号处理里有超时保护（比如系统级的 core dump 超时），有可能被中途打断。

守护进程的问题在于fork。fork出来的子进程会继承父进程的信号处理函数和内部状态，如果你的父进程在初始化了 Breakpad 之后又fork了一堆 worker，那么每个 worker 崩了都会各自写一份 dump，这通常是你想要的。但反过来，如果父进程 fork 后立刻exec了别的程序，那处理函数会被清掉，这也没问题。真正要小心的是"fork 之后子进程继承了 handler，但子进程并没有被设计成独立崩溃上报单元"，导致 dump 归属混乱。稳妥的做法是在fork之后根据角色显式地重新初始化或禁用 handler。

还有一种场景是程序被exec之前就崩了，或者在动态库加载阶段崩了，这时候 Breakpad 可能还没初始化完成，抓不到。这属于"启动早期崩溃"，解决思路是在main的第一行就初始化 handler，不要放在某个懒加载的单例里。启动早期崩溃占比不高，但一旦发生，往往是最难查的那一类，能抓到就一定要抓到。

4. 符号文件：栈能不能看懂全看这一步

4.1 MODULE ID 到底是怎么算出来的

这是整条链路里最需要理解清楚的一个概念。minidump 文件里记录每个已加载模块时，不只是记路径和基地址，还记了一个标识（在 Breakpad 的文本格式里叫 Module ID）。分析工具拿着这个标识去符号目录里找对应的子目录，目录名必须完全一致。

在 Linux 上，这个标识优先取 ELF 文件里的 GNU build-id，也就是.note.gnu.build-id段里那串十六进制。你可以在命令行里直接看到它：

readelf -n ./myapp | grep -i "build id" # Build ID: 6a1b2c3d4e5f60718293a4b5c6d7e8f901234567

如果编译时没有生成 build-id（某些嵌入式工具链默认不带），Breakpad 会退而求其次，对可执行段的内容做一次哈希，得到一个替代标识。关键在于：采集端和符号端用的是同一套算法，所以只要二进制文件是同一份产物，两边算出来的标识就一定一致。

这就引出两个非常实际的结论。第一，符号文件必须和线上运行的二进制严格对应，哪怕只改了一行代码重新编译，标识都会变，旧符号对新 dump 无效。所以每次发布都要把对应的.sym归档，命名上带上版本号和 git commit 短哈希，别用latest这种名字糊弄。第二，strip掉调试信息不会改变 build-id（只要你没显式删掉.note.gnu.build-id段），所以"用完整产物生成符号、用 strip 后的产物发布"这条路是通的，这也是标准做法。

4.2 标准符号目录与一键生成脚本

dump_syms的用法很朴素：读一个 ELF，往标准输出写.sym文本。

dump_syms ./myapp > myapp.sym head -n 1 myapp.sym # MODULE Linux x86_64 6A1B2C3D4E5F60718293A4B5C6D7E8F90 myapp

第一行就是模块信息：平台、架构、Module ID、模块名。注意 Breakpad 输出时会把 ID 转成大写，目录结构里也用大写，这一点在手工拼路径时容易搞错。

minidump_stackwalk找符号的方式是：在你给的符号根目录下，按<模块名>/<Module ID>/<模块名>.sym的结构去找。所以你要做的就是把生成的.sym摆到正确位置：

mkdir -p symbols/myapp/6A1B2C3D4E5F60718293A4B5C6D7E8F90 mv myapp.sym symbols/myapp/6A1B2C3D4E5F60718293A4B5C6D7E8F90/

手拼容易出错，写个脚本一次搞定，这个脚本我在好几个项目里都用过，可以直接抄：

#!/usr/bin/env bash # gen_symbols.sh <binary> <symbol_root> set -euo pipefail BIN="$1" SYM_ROOT="${2:-./symbols}" [ -f "$BIN" ] || { echo "binary not found: $BIN"; exit 1; } # 生成 .sym 到临时文件 TMP_SYM="$(mktemp)" dump_syms "$BIN" > "$TMP_SYM" # 从第一行解析模块名和 ID HEADER="$(head -n 1 "$TMP_SYM")" MODULE_NAME="$(echo "$HEADER" | awk '{print $5}')" MODULE_ID="$(echo "$HEADER" | awk '{print $4}')" DEST_DIR="$SYM_ROOT/$MODULE_NAME/$MODULE_ID" mkdir -p "$DEST_DIR" mv "$TMP_SYM" "$DEST_DIR/$MODULE_NAME.sym" echo "symbols -> $DEST_DIR/$MODULE_NAME.sym"

动态库也一样处理。一个稍微复杂点的程序会加载五六个自己编译的.so，每一个都要生成符号并摆进去，否则栈里对应的帧就会退化成???。这里有个实用技巧：构建完成后，遍历输出目录里所有 ELF 文件（用file命令判断），批量跑这个脚本，比一个个手工处理靠谱得多。

4.3 strip 与调试符号分离的正确姿势

发布包要小，符号要全，这两件事不矛盾，关键是顺序。

推荐流程是这样的：编译产物先原样保留一份到debug/目录（或者压缩归档到制品库），这份文件带着完整的调试信息，只用于dump_syms。然后对发布用的那份做剥离：

# 保留一份完整的 cp myapp myapp.debug # 生成符号（用完整的那份） ./gen_symbols.sh myapp.debug ./symbols # 剥掉调试信息用于发布 strip --strip-debug myapp # 或者更彻底 strip --strip-all myapp # 确认 build-id 没变 readelf -n myapp | grep -i "build id"

如果你希望发布包里还保留"能自动找到调试文件"的能力，可以用objcopy把调试信息和主文件关联起来：

objcopy --only-keep-debug myapp myapp.debug objcopy --strip-debug myapp objcopy --add-gnu-debuglink=myapp.debug myapp

这样用常规调试器打开myapp时，它会自动去同目录找myapp.debug。这套做法对 Breakpad 链路本身没有额外好处（我们本来就是用完整文件生成符号的），但对同时使用常规调试器的团队很友好。

注意：千万不要对已经strip过的文件跑dump_syms，然后指望能拿到函数名。剥离之后符号表就没了，dump_syms可能不报错，但生成的.sym里几乎全是空的，你会得到一个能成功生成、但解析 dump 时全是问号的符号文件。判断方法是看.sym的文件大小，正常的几 MB 程序的符号文件至少几十 KB 到几 MB，如果只有几百字节，那一定是剥过了。

5. 解析 minidump：从一堆十六进制到能读的栈

5.1 一次完整的解析演示

拿到一个.dmp，第一步先看看它有没有正确的模块信息：

minidump_dump crash.dmp | head -n 80

你会看到类似MDRawModule的条目，里面有模块名、模块标识、基地址。确认你的程序出现在列表里，并且标识和.sym第一行能对上。这一步花三十秒，能省掉后面半小时的困惑。

确认无误后，跑解析：

minidump_stackwalk crash.dmp ./symbols > crash.txt 2>&1

输出的报告长这样（内容做了简化）：

Operating system: Linux 0.0.0 Linux 5.15.0-91-generic #101 SMP ... x86_64 CPU: amd64 family 6 model 85 stepping 7 8 CPUs Crash reason: SIGSEGV /SEGV_MAPERR Crash address: 0x0 Process uptime: 12 seconds Thread 0 (crashed) 0 myapp!Foo::Compute(int) + 0x1c rax = 0x0000000000000000 rdx = 0x00007f3a1c0009c0 rip = 0x000055d4a1c2b3e0 rsp = 0x00007ffd4a3b1c20 Found by: given as instruction pointer in context 1 myapp!Bar::Run() + 0x87 rip = 0x000055d4a1c2b540 rsp = 0x00007ffd4a3b1c60 Found by: call frame info 2 myapp!main + 0x2a rip = 0x000055d4a1c2b6a0 rsp = 0x00007ffd4a3b1cb0 Found by: call frame info Thread 1 0 libc.so.6!__futex_abstimed_wait_common64 + 0x1b ...

这份报告的价值密度很高，下面逐项拆开看。

5.2 输出字段逐项解读

Crash reason是最先要看的字段。SIGSEGV /SEGV_MAPERR表示访问了没有映射的地址，通常是空指针解引用或者野指针；SEGV_ACCERR表示地址有映射但权限不对，典型是往只读段写数据，比如改字符串字面量或者越界写到了常量区；SIGABRT一般是程序自己调了abort()，常出现在断言失败或者未捕获异常；SIGFPE是算术异常，整数除以零居多；SIGBUS常见于内存映射文件被截断后访问。

Crash address是触发异常的地址。它是0x0时基本可以确定是空指针相关；是一个很小但非零的值（比如0x8、0x18）时，通常是访问了某个空对象指针的成员，偏移量就是这个字段在结构体里的位置，这个线索非常有用——你能直接推断出是哪个成员。是一个看起来正常但被释放过的地址时，就要怀疑悬垂指针或者并发释放。

Process uptime记录进程运行了多久才崩。如果只有几秒，说明是启动阶段的问题；如果稳定运行了几个小时才崩，多半和长期运行中的资源累积、内存增长、定时逻辑有关。这个字段在排查偶发崩溃时非常关键，比单纯看栈更有信息量。

线程部分，带(crashed)标记的就是出事的那个线程。每一帧的格式是帧号 模块名!函数名 + 偏移。这个偏移是相对于函数入口的指令偏移，配合源文件行号能定位到具体语句。如果某一帧显示+ 0x...一个很大的偏移（比如+ 0x4a2c），那这一帧大概率是错的，通常是栈被破坏后的错误回溯。

Found by字段表示这一帧是怎么被识别出来的，它直接反映可信度。given as instruction pointer in context是第 0 帧的标配，寄存器直接给的，绝对可信。call frame info表示用 CFI（调用帧信息）解出来的，通常可信。frame pointer表示用帧指针链推出来的，在开了-fomit-frame-pointer（-O2默认开）的情况下可能不准。scan表示工具在栈上暴力扫描找到的疑似返回地址，这种帧的可信度最低，可能出现"函数名对但层级不对"的情况。

理解了这一点，看栈的时候就不会被误导。如果你看到崩溃线程的栈在一堆可信度很高的帧之后突然跟了几帧Found by: scan，那基本可以判定后面的部分不作数，只看前几帧就行。

5.3 符号缺失时怎么快速定位

解析结果里出现???或module not found是很常见的，按下面的顺序排查，一般三分钟内能定位。

第一步，确认 minidump 里有没有记录这个模块。用minidump_dump看模块列表，如果模块压根不在，那是采集端的问题——说明崩溃发生时那个库还没加载，或者加载了但 Breakpad 读取 maps 失败（容器里/proc挂载受限时会这样）。

第二步，确认标识对不对。把minidump_dump里的模块标识和.sym文件第一行的第四列对比。大小写、前导零、长度都要一致。我踩过最蠢的一个坑是脚本里用了小写目录名，人眼看不出差别，工具就是找不到。

第三步，确认目录层级。必须是符号根目录/模块名/模块标识/模块名.sym，三层一个都不能少。模块名取自MODULE行的最后一列，不是文件名——有些工具链会把模块名写成带路径的形式，那就得按它写的来建目录。

第四步，确认符号文件本身不是空的。wc -l xxx.sym，正常的文件几万行起步。

这四步走完还对不上，那就用minidump-2-core把 minidump 转成 core，用常规调试器加载，至少能看到地址和模块映射关系，再从另一个角度推。

6. 线上落地：采集策略与自动化链路

6.1 磁盘、频率与文件大小控制

一个真实的教训：某次上线后有个空指针 bug，触发条件是某个特定接口被调用。这个接口的 QPS 很高，于是崩溃进程被守护进程拉起、再崩溃、再拉起，两个小时内myapp目录下堆了三万多个 minidump，把那块 20 GB 的数据盘写满了，然后整个服务因为写日志失败而彻底挂掉。崩溃本身没打垮服务，崩溃产生的副作用把它打垮了。

控制手段有三层。第一层是频率限制。在filter回调里做一次简单的计数判断，同一个进程实例在单位时间内最多写 N 个 dump，超了就返回false跳过。计数用原子变量即可，不要用锁。第二层是总量限制。采集目录外挂一个清理任务，按总大小做 LRU 淘汰，超过阈值就删最老的。第三层是落盘位置隔离。把 dump 目录放在独立分区或者tmpfs上（tmpfs会占内存，要评估），确保它写满不影响主业务。

文件大小方面，Breakpad 在 Linux 上会为每个线程 dump 栈内存，线程越多文件越大。如果你有一个几百线程的程序，可以考虑在初始化时通过参数控制只 dump 崩溃线程（具体开关看你的源码版本，不同版本能力不一样），或者在采集端做一次压缩。gzip一个典型的 minidump 能压到原体积的三分之一左右，传输和存储都划算。

6.2 一个够用的自动化解析脚本

下面这个脚本负责"拿到 dump、找对应版本的符号、输出报告"，是我们分析端的日常工具，逻辑简单但够用：

#!/usr/bin/env bash # analyze.sh <dump-file> <version> set -euo pipefail DUMP="$1" VERSION="$2" SYMBOL_ROOT="/data/symbols/$VERSION" OUT_DIR="/data/reports" [ -f "$DUMP" ] || { echo "dump not found: $DUMP"; exit 1; } [ -d "$SYMBOL_ROOT" ] || { echo "symbols missing for version $VERSION"; exit 1; } BASE="$(basename "$DUMP" .dmp)" mkdir -p "$OUT_DIR" minidump_stackwalk "$DUMP" "$SYMBOL_ROOT" > "$OUT_DIR/$BASE.txt" 2>&1 # 立刻把关键信息摘出来，方便批量筛选 { grep -m1 "Crash reason" "$OUT_DIR/$BASE.txt" || true grep -m1 "Crash address" "$OUT_DIR/$BASE.txt" || true grep -A3 "Thread 0 (crashed)" "$OUT_DIR/$BASE.txt" | head -n 5 || true } > "$OUT_DIR/$BASE.summary" cat "$OUT_DIR/$BASE.summary"

关键设计点是SYMBOL_ROOT按版本隔离。千万不要把所有版本的符号扔进同一个目录，虽然理论上 Module ID 不同不会冲突，但实际排查时你会分不清哪个是哪个版本，而且长期积累下来目录会有几十万个子目录，find都跑不动。按版本号/一层隔开，清理也方便，保留最近 N 个版本即可。

.summary那个文件是给批量分析用的。当你有几千个 dump 时，不可能一个个看完整报告，先按Crash reason和崩溃线程第 0 帧聚类，把数量最多的前几个签名挑出来，人工只看这几个，效率能提高一个数量级。这个思路和工业界的崩溃聚合是一致的：先聚类，再逐个击破。

6.3 与系统 coredump 机制共存

Breakpad 和系统 core dump 不是互斥的，两者可以同时开，但要理解它们的边界。

Breakpad 只处理它能捕获的信号，对于被SIGKILL或者被内核直接终止的进程，它什么都做不了，这种时候系统的 core dump 也未必有，因为信号 9 本身不产生 core。对于一些 Breakpad 处理失败的情况（比如 handler 自己崩了），系统 core 反而是最后的兜底。所以我的建议是：生产环境把系统 core 的ulimit设成一个较小但非零的值（比如 256 MB），core_pattern指向一个带 pid 和时间戳的模板，作为兜底；主力分析链路走 Breakpad。这样既不占大量磁盘，又不会在极端情况下什么都没有。

有一点要特别注意：如果系统的core_pattern是以管道形式交给外部程序处理的（比如|/usr/lib/systemd/systemd-coredump），那 core 文件的生成会走一个独立进程，这时候和 Breakpad 的同步写入可能会互相影响时序，表现为 dump 时间变长。如果你发现开启 Breakpad 后崩溃进程的退出延迟明显增加，可以先临时关掉系统 core 看看是不是这个原因。

7. 常见问题速查表

7.1 构建与链接

7.2 崩溃现场

7.3 符号与回溯

最后分享一个我自己一直在用的习惯：每次发布前跑一次"自测崩溃"。在预发环境跑一个带--self-test-crash参数启动的实例，让它主动触发一次空指针，然后把生成的 dump 走一遍完整解析链路，确认能解出正确的函数名和行号。这三十秒的验证，能避免上线后才发现符号没归档、目录拼错、版本对不上这类让人抓狂的问题。崩溃捕获这件事，平时不出事的时候看起来毫无存在感，真出事的那天，它决定了你是能在半小时内定位问题、还是对着一个Segmentation fault熬到天亮。