在寫大型c/c++工程時難免會發生記憶體洩漏現象，系統程式設計中乙個重要的方面就是有效地處理與記憶體相關的問題。你的工作越接近系統，你就需要面對越多的記憶體問題。有時這些問題非常瑣碎，而更多時候它會演變成乙個除錯記憶體問題的惡夢。 常見的記憶體問題一共七種：1. 動態記憶體洩露；2. 資源洩露，比如檔案指標不關閉；3. 動態記憶體越界；4.陣列記憶體越界；5.動態記憶體double free；6.使用野指標，即未初始化的指標；7.釋放野指標，即未初始化的指標。
記憶體問題非常難定位，對於小工程來說，簡單去檢查**中new和delete的匹配對數就基本能定位到問題，但是一旦**量上公升到以萬單位時，僅靠肉眼檢查來定位問題那就非常困難了，所以我們需要利用工具幫助我們找出問題所在。在linux系統下記憶體檢測工具首推valgrind，一款非常好用的開源記憶體管理框架。valgrind其實是乙個工具集，記憶體錯誤檢測只是它眾多功能的乙個，但我們用得最多的功能正是它——memcheck。
該工具可以檢測下列與記憶體相關的問題 :
首先安裝valgrind非常簡單：
valgrind安裝：
1. tar -jxvf valgrind-3.12.0.tar.bz2
2. cd valgrind-3.12.0
3. ./configure
4. make
5. sudo make install
下面開始講解valgrind的應用場景。
注意: 下面討論的所有測試**都應該使用gcc/g++並且加上-g選項。
這裡我們定義了乙個指標p，但並未給他開闢空間，即他是乙個野指標，但我們卻使用它了。
valgrind檢測出我們程式使用了未初始化的變數，但並未檢測出記憶體洩漏。
p所指向的記憶體被釋放了，p變成了野指標，但是我們卻繼續使用這片記憶體。
valgrind檢測出我們使用了已經free掉的記憶體，並給出這片記憶體是**分配**釋放的。
我們動態地分配了一段陣列，但我們在訪問個陣列時發生了越界讀寫，程式crash掉。
valgrind檢測出越界的位置。
注意：valgrind不檢查靜態分配陣列的使用情況！所以對靜態分配的陣列，valgrind表示無能為力！比如下面的例子，程式crash掉，我們卻不知道為什麼。
記憶體洩漏的原因在於沒有成對地使用malloc/free和new/delete，比如下面的例子。
valgrind會給出程式中malloc和free的出現次數以判斷是否發生記憶體洩漏，比如對上面的程式執行memcheck，valgrind的記錄顯示上面的程式用了1次malloc，卻呼叫了0次free，明顯發生了記憶體洩漏！
上面提示了我們可以使用--leak-check=full進一步獲取記憶體洩漏的資訊，比如malloc和free的具體行號。
正常使用new/delete和malloc/free是這樣子的：
而不匹配地使用malloc/new/new 和 free/delete/delete則會被提示mismacth：
double free的情況同樣是根據malloc/free的匹配對數來體現的，比如free多了一次，valgrind也會提示。
當然，valgrind也不是萬能的。valgrind也有無法找到問題的時候，有些問題只能通過不斷的review**找到了癥結。發現問題，解決問題，畢竟是末流。最好的方法，就是不引入記憶體問題。這可以通過良好的**風格和設計來實現的。
linux下記憶體洩露檢測
前段時間遇到一些關於記憶體方面的問題，使用了malloc stats來進行記憶體檢測。呼叫函式後，函式會把輸出定向到strerr中，內容如下，arena 0 第乙個arena 每個執行緒分配乙個arena 這裡只有乙個執行緒 system bytes 135168 本執行緒從作業系統獲得的動態記憶體...
linux下記憶體洩露檢測工具Valgrind介紹
目前在linux開發乙個分析實時路況的應用程式，在聯合測試中發現程式存在記憶體洩露的情況。這下著急了，馬上就要上線了，還好發現了一款valgrind工具，完美的解決了記憶體洩露的問題。推薦大家可以使用看看。valgrind是執行在linux上一套基於 技術的程式除錯和分析工具，它的主要作者是獲得過g...
Linux 記憶體洩露檢測
1.需要在記憶體洩露開始的開始呼叫void mtrace void mtrace 為malloc等函式安裝 hook,用於記錄記憶體分配資訊，在需要記憶體洩露檢查 結束的地方呼叫void muntrace void 注意 在一般情況下，不要呼叫muntrace 而讓程式自然結束。因為可能有些記憶體釋...