做為一位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的組建架構圖：

圖片來源：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】

總結

以上是生活随笔為你收集整理的core文件怎么分析_c++ crash 分析工具：breakpad的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。