c++ crash 分析工具:breakpad（crash分析vmcore）

做为一位c++开发人员，如果你没有遇到过线上程序崩溃，说明你写的代码少或者说你的测试同学很给力，或者是你的服务太简单了，这个题外话哈。俗话说，“夜路走多了总会遇到鬼（bug）”。

通常情况下我们生产环境的服务崩溃，如果你比较幸运的话你的程序会生成一个coredump文件（这个文件的路径可以通过/proc/sys/kernel/core_pattern配置）。但是先别高兴太早，这个core文件未必是完整的。因为core文件也有大小限制（简单的配置方法是通过ulimit -c进行配置）。

如果生成的core文件不完整，那么这个core文件相当于废物，因为他没有进程崩溃时完整的内存快照，没法进行调用堆栈分析，即使是完成的core文件那么你的程序也需要带-g进行编译吧否则你看到的是一堆？？？？？？，没有函数等符号信息。

如果连core都没有生成那怎么办呢？

可以通过查看Linux内存的日志：dmesg 然后借助addr2line 查看崩溃的函数，如果你的程序是带有-g编译的那你有可能会看到对应的崩溃的函数。

如果以上两种都没有，那怎么办呢？那你就只能gdb attach到进程，然后盯着它等它再次出现了，出现崩溃之后要快速bt查看调用栈，否则时间久了内存也会被回收掉。

为了避免出现以上低效的问题定位，这里给大家介绍一个非常实用的工具库：breakpad 是google顶级公司开源的项目，他的优势在于：

1）接入简单，短短几行代码就可以了

2）符号信息与生产环境上的程序分离

3）生成的崩溃文件极小，而且还能还原出崩溃的调用堆栈（mini coredump）

4）还能够支持通过http将mini coredump文件上传到指定的平台（用于做平台分析）

下面是google breakpad的组建架构图：

◆ client 以library的形式内置在你的应用中，当崩溃发生时写 minidump文件

◆ symbol dumper 读取由编译器生成的调试信息（debugging information），并生成 symbol file

◆ processor 读取 minidump文件 和 symbol file,生成可读的c/c++ Stack trace.

??大家使用的过程中需要注意提取的符号文件要放到指定相应的目录下。

使用步骤：

1）采用带有-g编译你的服务：a.out

2）采用google breakpad 符号提取工具：dump_syms 提取1）生成的可执行文件中的符号

dump_syms a.out > a.out.sym (??注意文件名格式：可执行文件+.sym)

然后通过:（将符号文件放到指定的目录下）

mkdir -p /tmp/`head -n1 a.out.sym|awk '{print $3}'/

mv a.out.sym /tmp/`head -n1 a.out.sym|awk '{print $3}'`/

3)重新编译你的服务此时可以把-g去掉

4）等待你的服务出现崩溃，崩溃时会生成一个文件：xxxx.dmp 默认时在/tmp目录下

5）分析生成堆栈

minidump_stackwalk xxx.dmp. /tmp/

以上用的几个工具都可以通过google breakpad 编译获得，源码在gitee上欢迎大家体验一起交流～【https://gitee.com/mirrors/breakpad?_from=gitee_search】