GDB 調試 C/C++ Project

平時作算法題目, 沒少用到 GDB, 但今天才意識到 Project 的調試方法與單個 cpp 文件的不一樣之處, 好比 gdb list 命令, 在單個 cpp 文件中列出的是源代碼, 但在 project 中卻什麼都不顯示算法

 

Project Debug 時, file 參數的使用 [1] 有講解, UP 主問的問題和我遇到的同樣, 只不過, 沒能解決個人問題(個人問題更2B一些).數組

 

出現的錯誤工具

1. 執行命令, make, gdb test, gdb lpost

No symbol table is loaded.性能

最終解決方法是在 make 裏, 每生成一個 .o 文件都須要 -g  參數開發工具

 

2. 段錯誤 segment faultspa

段錯誤是一種內存保護機制, 當進程訪問許可空間範圍之外的內存時便會引起內核的 "通常保護性異常", 內核向程序發出 SIGSEGV(11) 信號, 而這個信號的 handler 默認工做就是在控制檯打出一個 segment fault 併產生內核轉儲文件(Core), 結束掉當前正在運行的程序.操作系統

段錯誤的成因有一下幾種(不徹底統計)指針

2.1 程序訪問系統數據區, 好比對爲 NULL 的指針解引用, 或寫入數據調試

2.2 內存訪問越界 (數組越界)

2.3 對 malloc, new 申請的空間二次釋放

2.4 操做系統的段保護機制, 致使因緩衝區溢出而對非法內存訪問

2.5 無限遞歸, 致使堆棧溢出

2.6 fclose 對一個 FILE* 二次釋放

調試工具 Valgrind

Valgrind 是一款用於內存調試, 內存泄露檢測和性能分析的軟件開發工具, 但 Valgrind 只能檢測到堆的異常和泄露, 對棧的心有餘而力不足.

Valgrind 原理與用法

咱們剛纔提到段錯誤會引起內核轉儲(Core), Core 記錄了 down 掉程序的映像和一些調試信心, valgrind 須要 core, 可是並非全部的系統都默認提供 core, 可經過 ulimit -a 查看 core 是否默認設置, 我查了下, 本身的機器是 (blocks, -c) 0, 說明 core 默認不提供, 因此須要經過 ulimit -c 1024 來設置 core 大小. 但經過 ulimit 設置在重啓機器後失效.

咱們從新編譯本身出錯程序, 在 g++ 後加上 -g -rdynamic 參數, -g 是添加調試信心, 而 -rdynamic 是通知連接器把全部符號添加到動態符號表, 再次運行程序, ls, 會看到一個 core 開頭的文件, 咱們用 gdb ./yourprogram core 來查看是哪一個文件哪一行, 什麼代碼出現了異常. 假如你沒有看到 core 文件, 那麼從新檢查下 ulimit 設置.

 

Reference

[1] http://stackoverflow.com/questions/9245685/gdb-no-symbol-table-is-loaded

[2] http://through-my-eyes.diandian.com/post/2012-11-20/40043131231

相關文章
相關標籤/搜索