如何使用GDB調試Coredump文件

壹般這種情況都是因為數組越界訪問，空指針或是野指針讀寫造成的。程序小的話還比較好辦，對著源代碼仔細檢查就能解決。但是對於代碼量較大的程序，裏邊包含N多函數調用，N多數組指針訪問，這時想定位問題就不是很容易了（此時牛人依然可以通過在適當位置打printf加二分查找的方式迅速定位:P）。懶人的話還是直接GDB搞起吧。神馬是Core Dump文件偶爾就能聽見某程序員同學抱怨“擦，又出Core了！”。簡單來說，core dump說的是操作系統執行的壹個動作，當某個進程因為壹些原因意外終止（crash）的時候，操作系統會將這個進程當時的內存信息轉儲（dump）到磁盤上1。產生的文件就是core文件了，壹般會以core.xxx形式命名。如何產生Core Dump 發生doredump壹般都是在進程收到某個信號的時候，Linux上現在大概有60多個信號，可以使用 kill -l 命令全部列出來。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX針對特定的信號，應用程序可以寫對應的信號處理函數。如果不指定，則采取默認的處理方式, 默認處理是coredump的信號如下：3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我們看到SIGSEGV在其中，壹般數組越界或是訪問空指針都會產生這個信號。另外雖然默認是這樣的，但是妳也可以寫自己的信號處理函數改變默認行為，更多信號相關可以看參考鏈接33。上述內容只是產生coredump的必要條件，而非充分條件。要產生core文件還依賴於程序運行的shell，可以通過ulimit -a命令查看，輸出內容大致如下：sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 看到第壹行了吧，core file size，這個值用來限制產生的core文件大小，超過這個值就不會保存了。我這裏輸出是0，也就是不會保存core文件，即使產生了，也保存不下來==! 要改變這個設置，可以使用ulimit -c unlimited。 OK, 現在萬事具備，只缺壹個能產生Core的程序了，介個對C程序員來說太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 寫只讀存儲區! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手調試上邊的程序編譯的時候有壹點需要註意，需要帶上參數-g, 這樣生成的可執行程序中會帶上足夠的調試信息。編譯運行之後妳就應該能看見期待已久的“Segment Fault(core dumped)”或是“段錯誤 (核心已轉儲)”之類的字眼了。看看當前目錄下是不是有個core或是core.xxx的文件。祭出linux下經典的調試器GDB，首先帶著core文件載入程序：gdb exefile core，這裏需要註意的這個core文件必須是exefile產生的，否則符號表會對不上。載入之後大概是這個樣子的：sagi@sagi-laptop:~$ gdb coredump core Core was generated by ./coredump'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coredump.c:8 8 xxx[1] = 'D'; (gdb)我們看到已經能直接定位到出core的地方了，在第8行寫了壹個只讀的內存區域導致觸發Segment Fault信號。在載入core的時候有個小技巧，如果妳事先不知道這個core文件是由哪個程序產生的，妳可以先隨便找個代替壹下，比如/usr/bin/w就是不錯的選擇。比如我們采用這種方法載入上邊產生的core，gdb會有類似的輸出：sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coredump'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已經提示妳了，這個core是由哪個程序產生的。 GDB 常用操作上邊的程序比較簡單，不需要另外的操作就能直接找到問題所在。現實卻不是這樣的，常常需要進行單步跟蹤，設置斷點之類的操作才能順利定位問題。下邊列出了GDB壹些常用的操作。啟動程序：run設置斷點：b 行號|函數名刪除斷點：delete 斷點編號禁用斷點：disable 斷點編號啟用斷點：enable 斷點編號單步跟蹤：next 也可以簡寫 n單步跟蹤：step 也可以簡寫 s打印變量：print 變量名字設置變量：set var=value查看變量類型：ptype var順序執行到結束：cont順序執行到某壹行： util lineno打印堆棧信息：bt