gdb 調試coredump文件過程：
第一步：首先需要一個進程的coredump文件，怎么搞出coredump文件呢？
1、 ps -fax|grep 進程名稱 找到進程的pid
2、gdb -p pid 調試進程
3、gcore coredump名稱 則生成core文件
https://www.cnblogs.com/wangjian8888/p/11978397.html 該鏈接有應用程序崩潰后生成core文件具體方法
第二步：找出coredump文件的應用程序
1、gdb -c corefile 使用gdb調試core文件
2、info auxv 索引31對應的是core文件的應用程序
第三部：gdb使用應用程序調試coredump文件
gdb coredump應用程序 coredump文件 調試coredump文件
通過以上三步就可以調試coredump文件了
通過以下命令調試coredump文件
info threads 顯示所有線程
bt 顯示線程堆棧信息
thread thread_num 切換線程
frame num 切換棧
info r 顯示當前幀的寄存器信息 （每一幀的寄存器信息都是不相同的）
readelf應用coredump
readelf -h 讀取coredump文件頭
readelf -wl 讀取應用程序debug_line
readelf -wf 讀取應用程序fde和cie信息
gdb core 多線程
在linux環境下調試多線程，總覺得不像.NET那么方便。這幾天就為找一個死鎖的bug折騰好久，介紹一下用過的方法吧。
多線程如果dump，多為段錯誤，一般都涉及內存非法讀寫。可以這樣處理，使用下面的命令打開系統開關，讓其可以在死掉的時候生成core文件。
ulimit -c unlimited
這樣的話死掉的時候就可以在當前目錄看到core.pid(pid為進程號)的文件。接着使用gdb:
gdb ./bin ./core.pid
進去后，使用bt查看死掉時棧的情況，在使用frame命令。
還有就是里面某個線程停住，也沒死，這種情況一般就是死鎖或者涉及消息接受的超時問題(聽人說的，沒有遇到過)。遇到這種情況，可以使用：
gcore pid （調試進程的pid號）
手動生成core文件，在使用pstack(linux下好像不好使)查看堆棧的情況。如果都看不出來，就仔細查看代碼，看看是不是在 if，return，break，continue這種語句操作是忘記解鎖，還有嵌套鎖的問題，都需要分析清楚了。
最后，說一句，靜心看代碼，捶胸頓足是沒有用的。
多線程如果dump，多為段錯誤，一般都涉及內存非法讀寫。可以這樣處理，使用下面的命令打開系統開關，讓其可以在死掉的時候生成core文件。
ulimit -c unlimited
這樣的話死掉的時候就可以在當前目錄看到core.pid(pid為進程號)的文件。接着使用gdb:
gdb ./bin ./core.pid
進去后，使用bt查看死掉時棧的情況，在使用frame命令。
還有就是里面某個線程停住，也沒死，這種情況一般就是死鎖或者涉及消息接受的超時問題(聽人說的，沒有遇到過)。遇到這種情況，可以使用：
gcore pid （調試進程的pid號）
手動生成core文件，在使用pstack(linux下好像不好使)查看堆棧的情況。如果都看不出來，就仔細查看代碼，看看是不是在 if，return，break，continue這種語句操作是忘記解鎖，還有嵌套鎖的問題，都需要分析清楚了。
最后，說一句，靜心看代碼，捶胸頓足是沒有用的。