gdb 調試coredump文件過程

gdb 調試coredump文件過程：

第一步：首先須要一個進程的coredump文件，怎麼搞出coredump文件呢？

一、 ps -fax|grep                 進程名稱 找到進程的pid

二、gdb -p pid                     調試進程

三、gcore coredump名稱        則生成core文件

https://www.cnblogs.com/wangjian8888/p/11978397.html 該連接有應用程序崩潰後生成core文件具體方法

第二步：找出coredump文件的應用程序

一、gdb -c corefile   使用gdb調試core文件

二、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這種語句操做是忘記解鎖，還有嵌套鎖的問題，都須要分析清楚了。 最後，說一句，靜心看代碼，捶胸頓足是沒有用的。