2012-08-06 59 views
0

我正面臨內存在大型軟件中踐踏的問題。如何在Linux中調試踐踏問題

有時會出現SIGSEGV/SIGABRT觀察。理由主要是踐踏用戶或malloc空間內存。以mprotect-ed內存作爲「誘餌」,但沒有運氣。 實際上無法捕捉到trampler。從核心文件分析看來,腐敗也在malloc空間中發生(當前塊大小)。腐敗始終是單字節的,任何地點發生(我的意思是這樣這樣的模式,我可以把它叫做溢/下溢,像0xFF00FF00與0xFF003A00損壞)的可能方式調查

任何建議?

P.S - 無法附加valgrind。

在此先感謝。

+2

爲什麼你要立即排除在Linux系統(valgrind)上可能最好的選擇? – 2012-08-06 13:46:37

+0

試圖..但應用程序的性質,使我們無法綁定valgrind它.. – tuban 2012-08-06 13:57:28

回答

1

有幾個技巧,你可以嘗試。首先,檢查堆的一致性,參見here

你可能還想編寫一個鉤子,在其中寫DEDEDEDE到所有被釋放的內存,參見here編寫一個鉤子來做到這一點。

+0

實際上嘗試了這些。即使簽名被破壞,也沒有辦法趕上trampler ....想要一些建議,以趕上腐敗本身.. – tuban 2012-08-07 06:11:14

0

如果出現某種奇蹟,你可以以某種方式使相同的內存位置在連續運行時被損壞(或至少25%的時間或某物),你可以在該內存位置的gdb中使用數據斷點。

如果沒有發生這種情況,您是否嘗試過使用不同硬件上的軟件來排除硬件內存錯誤?雖然罕見的這種事情仍然會發生。

另一種選擇是嘗試預加載分配器,如libumem或谷歌的分配器,看看它是否可以檢測到任何內存問題。

我知道你說這不是一個選項,但如果你能以任何方式縮小問題的範圍,那麼valgrind真的很好 - 它在很多場合都有幫助。

最後,如果沒有這些選項取得成果你將不得不去更重量級的:

  • 如果你可以用這樣的檢查檢查你的數據結構的健全以某種方式,垃圾代碼。
  • 開始刪除代碼並查看問題是否消失。
  • 從頭開始重構或重寫代碼的可疑部分。
  • 受影響地區任何/所有代碼的多人同行評審。優選地,一個人對代碼非常熟悉,而另一個人具有領域知識,但不知道代碼(因爲當您不知道代碼所說的內容時,您會在查看時看到更容易的錯誤) 。
1

有任何數量的替代堆實現與各種形式的理智檢查,你鏈接到您的系統,而不是libc中的一個。常用的技術包括:

  • 分配較大的塊不是請求和任何訪問
  • 一每頁配置上,擁有不可訪問頁面兩側(如頁面錯誤放置護區周圍的請求塊的開頭和結尾)
  • 跟蹤分配的塊以及釋放那些
  • 走堆在低優先級的線程在尋找壞的東西

我花了很長時間試圖幾年前在一個嵌入式系統上發現了這樣一個問題 - 在正常運行數天後報告了這個問題。從來沒有讓我的辦公桌上的單位崩潰。我在書中嘗試了幾乎所有的技巧 - 包括徹底的代碼審計和PCLinting整個代碼庫。

我最終在兩個系統上將原因追蹤到錯誤的SDRAM速度等級。碰撞的那個比我桌上的那個略微更加邊緣化。最終證明,使用吹風機和一罐冷凍噴霧:/

如果您可以得到一個確認的位置重複踩踏,您的下一個端口將使用硬件輔助調試(大多數CPU允許這些日子)​​或基於ICE或JTAG的調試器。