使用valgrind來檢查記憶體洩漏

之前寫**，有少量的記憶體洩露，平時沒發現，長時間執行才發現問題。為以後更方便的檢測記憶體洩漏問題，於是學習使用了valgrind來對記憶體洩漏進行檢測。valgrind不止可以檢測記憶體洩露，但目前只使用這一功能。

1.安裝

./configure

make

make install

如遇提示許可權不夠，make前加sudo

如果想驗證是否安裝完成，在終端輸入valgrind --version，若安裝成功，會輸出相應版本，如圖

2.檢測記憶體洩漏

終端進入可執行檔案所在的資料夾，輸入

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --undef-value-errors=no --log-file=log .
/可執行檔名

即可在終端所在資料夾下生成log檔案，如圖

在log檔案最後會有個summary，其中對記憶體洩露進行了分類，總共有五類：

(1) 「definitely lost」意味著你的程式一定存在記憶體洩露； (2)」indirectly

lost」意味著你的程式一定存在記憶體洩露，並且洩露情況和指標結構相關 (3) 「possibly lost」

意味著你的程式一定存在記憶體洩露，除非你是故意進行著不符合常規的操作，例如將指標指向某個已分配記憶體塊的中間位置。 (4) 「still

reachable」意味著你的程式可能是沒問題的，但確實沒有釋放掉一些本可以釋放的記憶體。這種情況是很常見的，並且通常基於合理的理由。

(5)」suppressed」意味著有些洩露資訊被壓制了。在預設的 suppression 檔案中可以看到一些 suppression

相關設定。

其中，如果二叉樹的根節點被判定為」definitely lost」，則其所有子節點將被判定為」indirectly lost」，而如果你正確修復了型別為「definitely lost」的根節點洩露，那麼型別為「indirectly lost」的子節點洩露也會隨著消失。

對於如上圖所示的情況，posslbly lost其實並沒有造成記憶體上的影響，如果想要過濾掉該類報告資訊，可以加入**–show-possibly-lost=no** ，而對於」still reachable」，同樣可以通過**–show-reachable=yes**來控制是否輸出相應的資訊。

如果某些需要的庫沒有找到，用指令進行新增

export ld_library_path= /usr/local/mysql/lib:$ld_library_path

3.檢視發生洩露的具體位置在log中由summary往上翻即可看到對應的錯誤，錯誤是不斷細化的，比如

這樣的是乙個錯誤，先告訴你出現了多少的記憶體洩露，然後從最裡層不斷往外部函式顯示：先說是calloc造成的錯誤，然後不斷往外部函式顯示。可以從下往上進行檢視，比如先說main()函式發生了洩露，往上看到是main()中的init()函式，再往上init()中的init_detectionmodel，如此不斷細定位洩露位置。

使用valgrind來檢查記憶體洩漏

使用valgrind來檢查記憶體洩漏

記憶體檢查工具valgrind

安裝Valgrind並檢查記憶體洩露

使用valgrind來檢查記憶體洩漏

使用valgrind來檢查記憶體洩漏

記憶體檢查工具valgrind

安裝Valgrind並檢查記憶體洩露

相關推薦