溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
最近項目中出現了一個問題，服務器端程序會突然崩潰退出，我們采取了coredump技術以找到崩潰原因，即確定進程退出時正在執行的函數是哪個，其狀態如何。
如果系統開啟了coredump，準確的說如果當前的shell環境開啟了coredump，當前shell環境下的程序崩潰退出時，會把當時進程的棧的內存狀態寫入core文件。使用gdb可以查看這個core文件中保存的棧的狀態，gdb a.out core。（關于coredump的開啟和對shell的理解，請參考本人另一篇博客《使用dotnet-dump 查找 .net core 3.0 占用CPU 100%的原因解析》，關于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函數。 ————————————————
總結
以上所述是小編給大家介紹的Linux下利用coredump技術追查進程崩潰原因，希望對大家有所幫助，如果大家有任何疑問歡迎給我留言，小編會及時回復大家的！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
