gdb用法（二） 在Linux下產生並調試core檔案

分析核心（core）檔案

 

在程式發生崩潰時，有時可能無法直接運行GDB來進行調試。比如程式可能是在另外一台機器上啟動並執行，或者因為程式對時間比較敏感，所以手動跟蹤調試會產生無法接受的延遲等。遇到這些情況，就只能等到程式運行結束後才能判斷崩潰的原因了。這時需要用到Linux提供的core dump機制。當程式中出現記憶體操作錯誤時，會發生崩潰併產生核心檔案。使用GDB可以對產生的核心檔案進行分析，找出程式是在什麼時候崩潰的和在崩潰之前程式都做了些什麼。當然，如果要用GDB來分析核心檔案，也必須在編譯時間加上-g選項來產生偵錯符號表。

在分析核心檔案之前必須確認系統是否允許產生核心檔案，很多Linux發行版在預設時禁止產生核心檔案。為了產生核心檔案，首先必須執行下面的命令：
# ulimit -c unlimited
然後就可以產生核心檔案了。

 

$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux

再看看預設的一些參數，注意core file size是個0，程式出錯時不會產生core檔案了。

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

 

這裡仍以前面的debugme程式為例，再次執行下面命令將產生核心檔案：

# ./debugme Enter a string to count words:Happy new year! The number of words is 3. Segmentation fault (core dumped)

產生的核心檔案名稱根據系統配置的不同會有所差異。要在GDB中分析核心檔案，除了要給出核心檔案的檔案名稱外，還必須給出產生該核心檔案的可執行程式的名稱，樣本如下：

#gdb debugme core.547 …… Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. ……

從GDB的輸出資訊中可以看出，產生這個核心檔案的原因是因為程式收到了序號為11的訊號。如果想知道程式在崩潰之前運行到了哪裡，可以使用“backtrace”或“info stack”命令查看一下堆棧的記錄。樣本如下：

(gdb) info stack #0 0x4000c6ac in _dl_fini () from /lib/ld-linux.so.2 #1 0x40057940 in exit () from /lib/libc.so.6 #2 0x4004291f in _libc_start_main () from /lib/libc.so.6

由上可知，程式崩潰時正處於_dl_fini()函數之中。但很多時候程式員感興趣的可能並不是這個，而是exit()或_libc_start_main()函數，因為它們才可能是問題真正的癥結所在。GDB提供的“frame”命令可以用來在不同的調用上下文中切換。例如下面的命令可以查看exit()函數在執行時的狀況：

(gdb) frame 1 #1 0x40057940 in exit () from /lib/libc.so.6

此外還可以用“up”或“down”命令在不同的函數調用上下文中切換。開發人員使用這三條命令可以很輕鬆地實現調用棧的遍曆。在分析核心檔案時，通過將遍曆棧的命令和檢查變數值的“print”命令結合起來，就能夠複原程式運行時的全部景象。