Linux下利用coredump技術追查進程崩潰緣由

原文連接：https://blog.csdn.net/u014585564/article/details/68063269

 

最近項目中出現了一個問題，服務器端程序會忽然崩潰退出，咱們採起了coredump技術以找到崩潰緣由，即肯定進程退出時正在執行的函數是哪一個，其狀態如何。

       若是系統開啓了coredump，準確的說若是當前的shell環境開啓了coredump，當前shell環境下的程序崩潰退出時，會把當時進程的棧的內存狀態寫入core文件。使用gdb能夠查看這個core文件中保存的棧的狀態，gdb a.out core。（關於coredump的開啓和對shell的理解，請參考本人另外一篇博客《由coredump的開啓引發的對shell的深刻探究》，關於gdb請參考《GDB觀察棧的內存佈局》）

       core文件生成的位置默認是可執行文件所在的位置，名稱默認爲core，其位置和名稱是能夠設置的，個人設置爲：

                                                                                            mkdir /home/corefile

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

       這樣，生成的core文件會放在/home/corefile目錄下，core文件名會以core-%e-%p-%t的形式出現，其中%e表示可執行文件的名稱，%p表示進程，%t表示生成core文件的時間（注意是unix時間）。

下面是一個能夠致使coredump的例程：

 

 
劃線處是會致使coredump處。執行後會在/home/corefile目錄下產生如下文件：

[root@localhostwin7]# ls /home/corefile/

 

 

a.out是可執行文件名，5082是PID，1490760381是產生該文件的unix時間。把a.out 和core文件放在一個目錄下，使用命令：

gdb  a.out  core-a.out-5082-1490760381

進入gdb，而後使用backtrace命令，便可看進程退出時的棧的內存狀態，以下所示：

 

 
 可見，進程退出時，執行的最後一個函數是square函數。
————————————————