打開 core dump 和使用 cgdb 檢查程式掛點原因

前置動作

首先, 用 gcc/g++ 編程式時記得加 -g 以加入除錯資訊。

接著參考《產生 core dump 的方法》設成可以產生 core dump。

檢查 backtrace

$ gdb PROGRAM

然後在 gdb 內執行

core core.PROGRAM.PID.TIMESTAMP

接著就能用 bt N 看最底層 N 個 call stack 為何, 也就是所謂的命案現場啦。然後可用 up, do, l 等指令切換 call stack 和列出週圍程式。

在和 gdb 相處一段時間後, 覺得這樣在 stack 之間移動很方便, 但看週圍的程式太辛苦了, 還是會開另一個視窗用 VIM 看完整一些的程式。

看到 jserv 建議使用 cgdb, 試了發現, 人生...啊不, 是視窗變彩色的了!! 不只有彩色的程式碼, 還外加類 VI 的瀏覽方式, 相當順手。

目前有用到的功能如下:

  • 按 i、ESC 在程式碼視窗和 gdb 命令列之間切換。
  • 程式碼視窗裡可用 VI 的部份指令移動行數; 回到命令列後和 gdb 完全相容, 可按上下鍵選用之前的指令。
  • 在程式碼視窗按空白鍵加減 break point。

官網文件有詳細的說明, 之後來掃一遍, 看有什麼好東西可用。

留言

  1. 所以不建議用 gdb 直接跑程式到掰掉後再檢查 XD? 我自己都是這樣子用,我還蠻好奇的。

    回覆刪除
  2. 寫的時候忘了也可以這樣跑 XD 另外 multi-process/thread 時比較不方便一點。

    回覆刪除
  3. 有遇過,用gdb直接attach上去之後,問題就重製出不來了... 囧rz
    所以還是乖乖開core dump吧!

    cgdb 比起 gdb --tui好用多了!

    若想直接在vim裡跑的話, clewn這個透過patch vim方式的專案 http://clewn.sourceforge.net/ 可以達到,可以比擬 emacs ,但還正沒有整得那麼好!!
    clewn個人用了一陣子,對於VIMer很吸引人,Trace code 很方便,但我覺得唯一美中不足的,就是按tab時的auto complete部份,作得不是那麼的漂亮,個人一點點小心得!

    回覆刪除
  4. 謝啦, 目前大多在看程式碼, 沒有頻繁地改程式和跑程式, 還沒這種需求。待有需求後來試試。

    回覆刪除
  5. http://fred-zone.blogspot.com/2010/09/debugging-mode.html

    突然想到這篇文章,雖然沒什麼關係,但是還是想提一提 XD

    回覆刪除
  6. 啊, 這和下一篇較相關
    http://fcamel-life.blogspot.com/2011/12/cc-debug.html

    剛好提醒我要多留意 configure 做的事, 應該在那邊有就類似的機制開關 debug flag, 不用手動加 #define

    回覆刪除

張貼留言

這個網誌中的熱門文章

virtualbox 使用 USB 裝置

熟悉系統工具好處多多

如何 git merge 更改檔名的檔案