分析字符串替換內存泄漏

我一直在試圖分析執行批量代碼時發生的泄漏。泄漏發現在dbx中，泄漏如下所示。分析字符串替換內存泄漏

Total  Num of Leaked  Allocation call stack 
    Size  Blocks Block 
        Address 
========== ====== =========== ======================================= 

272033 4431  -  operator new < std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep < std::basic_string<char,std::char_traits<char>,std::allocator<char> >::replace

有沒有人遇到這種類型的泄漏。是否可以使用DBX註釋分析泄漏。因爲它是一個巨大的代碼gussing在代碼泄漏的位置是艱難的

來源

2012-05-02 sandy

你確定它確實是泄漏嗎？你見過這個過程的規模在增長嗎？我問的原因是我通常看到的工具報告泄漏不一定是真實的泄漏 - 通常在可靠的第三方代碼中。 –

是的，確保過程大小像任何事物一樣增長。它的增長方式是堆棧的整個內存都會丟失，並且進程因沒有內存而崩潰。這是在重複測試過程中發生的。 – sandy

那麼，公平的評論。有一種工具，比如'淨化'（儘管它是商業的），你應該可以使用，儘管它只能識別它發生的地方，如果它在STL中，那麼這是一個更大的問題。我還在下面發佈了一條您可能會覺得有用的鏈接。 –

我會嘗試運行與libumem這有助於識別內存管理問題的應用程序。

即使代碼庫是巨大的，您也許可以通過針對代碼審查工作。

來源

2012-05-02 11:06:44

快速檢查行顯示this issue這看起來類似於你所看到的。這是非常古老的 - 你使用的是什麼編譯器版本？

如果它是同樣的問題，並且完全升級不可能，那麼您的困難將會隔離代碼被調用的地方並對其進行重構以防止它發生。

來源

2012-05-03 11:45:50

分析字符串替換內存泄漏

回答

相關問題