Linux Debugging（五）: coredump 分析入門

        作為工作幾年的老程式猿，肯定會遇到coredump，log severity設定的比較高，導緻可用的log無法分析問題所在。 更悲劇的是，這個問題不好複現！是以現在你手頭唯一的線索就是這個程式的屍體：coredump。你不得不通過它，來尋找問題根源。

      通過上幾篇文章，我們知道了函數參數是如何傳遞的，和函數調用時棧是如何變化的；當然了還有at&t的彙編基礎，這些，已經可以使我們具備了一定的調試基礎。其實，很多調試還是需要經驗+感覺的。當然說這句話可能會被打。但是你不得不承認，随着調試的增多，你的很多推斷在解決問題時顯得很重要，是以，我們需要不斷積累經驗，來面對各種case。

     導緻coredump的原因很多，比如死鎖，這些還不要作業系統相關的知識，這些問題的分析不在本文的讨論範圍之内。大家敬請期待接下來的文章吧！本文從一個非常典型的coredump入手。

     請下載下傳本文用到的coredump： linux debugging: coredump 分析入門的材料

     首先使用gdb a.out core.25992打開這個core

     看一下backtrace是什麼：   

出錯的地方很奇怪，而且整個callstack都被破壞了，是以首先看一下寄存器和bp是否正常：

rbp的值很奇怪，基本确定棧被破壞了（bt不正常，也應該看一下棧是否出問題了）。列印一下棧的内容，看是否棧被寫壞了：

我們看到了特殊的字元!,1234567890。當然實際的生産環境可能不會這麼簡單，比如筆者曾經遇到過這個字元串是/local/share/tracker_...這種目錄的字元串，後來發現拼接路徑的時候出現錯誤導緻路徑非常長，在路徑拷貝的時候出現了寫壞棧的情況。

多列印一下棧的内容：

可以看出，字元串"hello, world!,1234567890"這個字元串溢出導緻棧被破壞。

我們不應該用rbp列印嗎？

      還記得在函數傳回時，rbp會恢複為上一層調用者的bp嗎？因為字元串溢出/越界，導緻已經恢複不了原來的bp了。

       這個bug很簡單。實際上，有的coredump就是這種無心的錯誤啊。

尊重原創，轉載請注明出處： anzhsoft  http://blog.csdn.net/anzhsoft/article/details/18762915