Linux程序崩潰原調試

簡介

每個開發服務主程的同學可能都有程序崩潰的經曆，這時候就要了解點Linux下程序調試方法了。

以下資訊都有助于調試：

• 良好的程式編碼，有日志記錄
• 崩潰時産生了core檔案
• 通過dmesg檢視核心日志資訊

調試程序崩潰的方法有很多，可以根據具體需求使用。

調試

一般的調試流程，先從容易擷取的資訊入手，直到找到原因為止。

1. 程序日志

• 在程式開發中，肯定會記錄一些日志，而日志記錄的好壞可以直接影響調試，進而影響程式的釋出程序。
• 目前有很多的開源日志庫，選擇合适的即可。如log4cplus等。
• 日志等級較多時，一般在運作時，隻記錄WARN級别以上資訊，如果有實時調整日志級别，将非常有助于定位問題。
  • 實時打開DEBUG級别日志，能詳細跟蹤程式流程
  • 如果不能實時調整，隻能重新開機的方式，這時bug可能不易複現
• 日志的記錄也是需要特别注意的，這裡不展開講，因為沒有統一的标準，大家可以多參考開源及網上經驗總結，再結合實際應用到自己的項目中。

1. core檔案

• 生産環境可能不會産生core檔案，這時日志的記錄就尤其重要了。
• 測試環境建議先打開核心轉儲：

  ulimit -c unlimited

  ，或者調試到配置裡，不用每次開個終端都要設定一遍。
• 注意，core檔案與編譯時的

  -g

  選項結合使用，且編譯時不要加

  -O2

  ，否則gdb會看不到調試資訊。
• 使用

  gdb -c core a.out

  調試，

  bt

  列印崩潰時的棧資訊，基本可以發現出問題的代碼行
• 更多gdb的指令可以檢視相關man page，基本介紹可以參考核心轉儲-coredump簡介。

1. demsg

• 列印核心日志資訊
• 系統級别相關的資訊會存儲在此處，如程序異常崩潰退出等，也會有記錄
• 當一個程序使用的記憶體較大時，會被作業系統kill掉，這樣的資訊就會記錄在dmesg中，如

[1892837.939243] Out of memory: Kill process 10735 (oomServer) score 952 or sacrifice child
           

• 根據程序異常崩潰資訊，可以反推崩潰位置

[5596955.061423] traps: TrapServer[32530] trap divide error ip:4bb78a sp:7ff530ff7230 error:0 in TrapServer[400000+251000]
           

• 根據ip位置，使用

  addr2line -e TrapServer 4bb78a

  可列印程序的行号

1. gdb

• 已經介紹過的gdb結合core檔案
• 另外gdb可跟蹤運作中的程式，使用

  attach pid

  指令可直接attach到程序或者線程，bt檢視其運作的棧資訊，這種方式容易定位死鎖的程序

1. strace

• 'strace -p pid’即可列印出程序的系統調用資訊，包括參數，傳回值等
• 它還能調試程序接收到的信号情況
• 頻繁地系統調用會影響性能，這個指令可以用來調試性能及bug

小結

作為一名程式員，寫bug是不可避免的。

解決bug也是不可避免的。方法有千萬種，選擇最合适的就好。