跟蹤生產Linux服務器上的內存損壞

Question

大家好嗎，請你推薦一個工具，用於在使用c ++構建並在linux x86_64下工作的生產多線程服務器上發現內存損壞？ 我目前面臨以下問題：每隔幾個小時我的服務器崩潰並出現段錯誤，核心轉儲顯示錯誤發生在malloc / calloc中，這絕對是內存在某處被破壞的標志。

實際上我已經嘗試了一些沒有太多運氣的工具。 這是我迄今為止的經歷：

• Valgrind是一個偉大的（我甚至說是最好的）工具，但它使服務器的速度變慢，使其無法在生產中使用。 我在舞台服務器上嘗試了它，它確實幫助我找到了一些與內存相關的問題，但即使在修復它們之后，我仍然會在生產服務器上崩潰。 我在Valgrind下運行了我的舞台服務器幾個小時，但仍然無法發現任何嚴重的錯誤。

• 據說ElectricFence是一個真正的記憶豬，但我甚至無法讓它正常工作。 它幾乎立即在舞台服務器上的隨機奇怪的地方發生了段落，而Valgrind根本沒有表現出任何問題。 也許ElectricFence不支持線程化？我不知道。

• 杜馬 - 和ElectricFence一樣，但更糟糕的是。 雖然EF產生了具有可讀回溯的核心轉儲，但DUMA只顯示“?????”（並且肯定服務器使用-g標志構建）

• dmalloc - 我將服務器配置為使用它而不是標准的malloc例程，但它會在幾分鍾后掛起。 將gdb附加到進程顯示它掛在dmalloc中的某處:(

我漸漸變得瘋狂，根本不知道接下來該做什么。 我有以下工具要嘗試：mtrace，mpatrol但也許有人有更好的主意？

我非常感謝你對這個問題的任何幫助。

更新：我設法找到了錯誤的來源。 但是我發現它在舞台服務器上沒有生成一個使用helgrind / DRD / tsan - 幾個線程之間有一個datarace導致內存損壞。 關鍵是使用適當的valgrind抑制，因為這些工具顯示太多的誤報。 我仍然不知道如何在沒有任何顯着減速的情況下在生產服務器上發現這一點......

Answer 1

是的，C / C ++內存損壞問題很嚴重。 我也曾多次使用過valgrind，有時它會發現問題而有時候卻沒有。

在檢查valgrind輸出時，不要過於忽略其結果。 有時經過相當長的一段時間后，你會發現valgrind首先給你了解線索，但是你忽略了它。

另一個建議是比較以前已知的穩定版本的代碼更改。 如果您使用某種源版本控制系統（例如svn），這不是問題。 檢查所有與內存相關的功能（例如memcpy，memset，sprintf，new，delete / delete []）。

Answer 2

使用gcc 4.1和-fstack-protector-all開關編譯程序。 如果內存損壞是由堆棧粉碎引起的，那么應該能夠檢測到它。 您可能需要使用SSP的一些其他參數。

Answer 3

伙計們，我設法找到了這個bug的來源。 但是我在舞台服務器上使用helgrind / DRD / tsan發現它 - 在幾個線程之間存在一個datarace導致內存損壞。 關鍵是使用適當的 valgrind抑制，因為這些工具顯示太多的誤報。 我仍然不知道如何在沒有任何顯着減速的情況下在生產服務器上發現這一點......

Answer 4

你試過-fmudflap嗎？ （向上滾動幾行以查看可用選項）。

Answer 5

你可以嘗試IBM凈化，但我擔心這不是開源..

Answer 6

Google Perftools ---這是開源的 - 可能會有所幫助，請參閱堆檢查文檔。

Answer 7

試試這個： http ： //www.hexco.de/rmdebug/我廣泛使用它，它對性能的影響很小（它主要影響ram的數量），但分配算法是相同的。 它總是被證明足以找到任何分配錯誤。 一旦發生錯誤，您的程序就會崩潰，並且會有詳細的日志。

Answer 8

我不確定它是否會捕獲您的特定錯誤，但MALLOC_CHECK_環境變量（ malloc手冊頁 ）會在默認的Linux malloc實現中啟用其他檢查，並且通常沒有顯着的運行時成本。