之前寫程式碼，有少量的記憶體洩露，平時沒發現，長時間執行才發現問題。為以後更方便的檢測記憶體洩漏問題，於是學習使用了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，如此不斷細定位洩露位置。