段錯誤Segment Fault定位,即core dump文件與gdb定位

    使用C++開發系統有時會出現段錯誤,即Segment Fault。此類錯誤程序直接崩潰,一般沒有任何有用信息輸出,很難定位bug,於是無從解決問題。今天咱們介紹core dump文件,並使用gdb進行調試,以此來定位段錯誤問題。此文同時用以備忘。bash

 

1、core dump服務器

Core dump也稱核心轉儲, 當程序運行過程當中異常退出時, 由操做系統把程序當前的內存情況存儲在一個core文件中, 稱之爲core dump文件。ide

系統默認不生成core dump文件,可使用ulimit命令進行查看和設置。spa

查看。使用ulimit -c ulimit -a命令查看core dump文件大小,若是core file size0,則表示此時系統不會自動生成core dump文件,具體狀況如圖1所示。操作系統

wKioL1RtUgegqo2HAAJYCKi5u3o680.jpg

圖1.net

設置。咱們能夠經過ulimit-c unlimited命令,將core file size設置爲不受限制unlimited,以此配置系統,使之能夠自動生成coredump文件,具體操做如圖2所示。調試

wKioL1RtUkGTLdz6AAJp9V510AI777.jpg

圖2
blog

    

2、段錯誤程序進程

咱們編寫一段簡單的段錯誤程序,將之命名爲core_test.cpp,代碼以下。編譯運行,系統自動產生了core文件,如圖3所示。內存

#include<assert.h>
 
int main() {
    assert(0);
    return 0;
}

wKioL1RtUwWh4T3JAAFTbrm8PuU480.jpg

圖3

3、core文件命名

在生產環境中,一臺服務器上運行的程序較多,若是全部程序的core dump文件都自動命名爲core,則可能形成必定的混亂。爲此,咱們能夠經過設置,使得系統在爲core dump文件命名時註明更多信息。

        進程號。經過如下設置,可使core dump文件名爲core.pid形式。如圖4所示,系統自動生成了core.3430文件。

echo "1" >/proc/sys/kernel/core_uses_pid


wKiom1RtUsnBtOR-AALfUI2n0aI075.jpg

圖4

更多信息。經過如下設置,可使core dump文件名爲core-exe-pid-time形式。如圖4所示,系統自動生成了core-core_test-3465-1416037828文件。

echo 「/coredir/core-%e-%p-%t」 > /proc/sys/kernel/core_pattern/

wKioL1RtU4nS6Vo-AANcYWoLp7E883.jpg5

    若是咱們想進一步訂製core文件的名稱,能夠根據表1的信息,進行設置。

表1

%% 單個%字符

%p 進程ID

%u 進程實際用戶ID

%g 進程的實際組ID

%s 致使本次core dump的信號

%t core dump的時間戳 (197011日計起的秒數)

%h 主機名

%e 程序文件名


4、使用gdb定位core dump錯誤

部分博友的博客中提到使用gdb –c corewhere命令定位錯誤。或許是由於配置不一樣,我實際操做後發現若是使用gdb –c core,則得到的定位信息不具備可讀性,具體如圖6所示。

wKiom1RtU42zZY7WAARpO1hwGAo597.jpg

圖6

最終,我使用gdb core_test core命令(其中core_test是發生dump的可執行程序,corecore file),進入gdb後,再使用where命令,能夠定位到發生dump的代碼位置,而且具備良好的可讀性,具體如圖7所示。

wKioL1RtVC_Qz0RGAAd1b_ZMjqA244.jpg

圖7


參考

http://blog.csdn.net/ithomer/article/details/5945152

相關文章
相關標籤/搜索