什麽是coredump？

Coredump叫做核心轉儲，它是進程運行時在突然崩潰的那一刻的一個內存快照。操作系統在程序發生異常而異常在進程內部又沒有被捕獲的情況下，會把進程此刻內存、寄存器狀態、運行堆棧等信息轉儲保存在一個文件裏。

該文件也是二進制文件，可以使用gdb、elfdump、objdump或者windows下的windebug、solaris下的mdb進行打開分析裏面的具體內容。

ulimit -c 可以設置core文件的大小，如果這個值為0.則不會產生core文件，這個值太小，則core文件也不會產生，因為core文件一般都比較大。

使用ulimit -c unlimited來設置無限大，則任意情況下都會產生core文件。

ulimit -a可以查看當前core文件限制。

gdb 調試coredump的簡單示例

#include "stdio.h"
#include "stdlib.h"

void dumpCrash()
{
    char *ptr = "test";
    free(ptr);
}
int main()
{
    dumpCrash();
    return 0;
}

如上代碼，pStr指針指向的是字符串常量，字符串常量是保存在常量區的，free釋放常量區的內存肯定會導致coredump。

gcc -o dump test.c

運行test產生core文件,接下來利用gdb來調試coredump。

1、查看coredump時的堆棧。查看堆棧使用bt或者where命令

2、未gcc -g的話，沒有調試信息的情況下，打開coredump堆棧，並不會直接顯示core的代碼行。

此時，frame addr(幀數)或者簡寫如下，f 4 跳轉到core堆棧的第1幀。因為第0幀，1幀，2幀，3幀都是libc的代碼，已經不是我們自己代碼了。disassemble打開該幀函數的反匯編代碼。

如下箭頭（紅標）位置表示coredump時該函數調用所在的位置

[root@tlinux /]# gdb dump core.89056
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7

不過上面的free使用去掉名詞修飾效果和之前還是一樣的。但是我們可以推測到這裏是在調用free函數。

如此，我們就能知道我們coredump的位置，從而進一步能推斷出coredump的原因。

當然，現實環境中，coredump的場景肯定遠比這個復雜，都是邏輯都是一樣的，我們需要先找到coredump的位置，再結合代碼以及core文件推測coredump的原因。

gdb調試core dump使用