使用GDB調試Coredump檔案

轉自：http://blog.ddup.us/?p=176

寫C/C++程式經常要直接和記憶體打交道，一不小心就會造成程式執行時產生Segment Fault而掛掉。一般這種情況都是因為數組越界訪問，null 指標或是野指標讀寫造成的。程式小的話還比較好辦，對著原始碼仔細檢查就能解決。但是對於代碼量較大的程式，裡邊包含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)SIGSYS5)SIGTRAP   24)SIGXCPU  25)SIGXFSZ  29)SIGIOT

我們看到SIGSEGV在其中，一般數組越界或是訪問null 指標都會產生這個訊號。另外雖然預設是這樣的，但是你也可以寫自己的訊號處理函數改變預設行為，更多訊號相關可以看參考連結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