有多種方法來定義「記憶體洩漏」。
特別地，在程式設計師中通常使用的「記憶體洩漏」的兩個主要定義。
「記憶體洩漏」的第乙個常用定義是「記憶體已分配，並且在程式終止之前不會被釋放。
然而，許多程式設計師（正確地）認為，符合該定義的某些型別的記憶體洩漏實際上不會引起任何問題，因此不應該被認為是真正的「記憶體洩漏」。
「記憶體洩漏」的乙個可以更嚴格（更有用的）定義是「記憶體被分配，並且隨後不能被釋放，因為程式不再具有任何指向所分配的記憶體塊的指標。
換句話說，你不能釋放你不再有任何指標的記憶體。
因此，這樣的儲存器是「儲存器洩漏」。
valgrind使用這個更嚴格的術語「記憶體洩漏」的定義。
這是可能引起顯著堆損耗的洩漏型別，特別是對於長壽命過程。
valgrind的洩漏報告中的「still reachable」類別指的是僅適合「記憶體洩漏」的第乙個定義的分配。
這些塊沒有被釋放，但是它們可以被釋放（如果程式設計師想要的話），因為程式仍然在跟蹤那些儲存器塊的指標。
一般來說，沒有必要擔心「still reachable」塊。
他們不會造成真正的記憶體洩漏可能導致的問題。
例如，通常沒有從「still reachable」塊的堆耗盡的可能性。
這是因為這些塊通常是一次性分配，其引用在整個過程的生存期內保持。
雖然可以通過並確保您的程式釋放所有分配的記憶體，但通常沒有實際的好處，因為作業系統將在程序終止後**所有程序的記憶體。
與真正的記憶體洩漏對比，如果不固定，如果執行時間足夠長，可能會導致程序執行記憶體不足，或者只是導致程序消耗比必要的更多的記憶體。
可能唯一確保所有分配具有匹配的「釋放」的時間是，如果你的洩漏檢測工具不能告訴哪些塊是「still reachable」（但valgrind可以這樣做），或者如果你的作業系統不收回所有
終止程序的記憶體（valgrind已經移植到的所有平台）。
1. "只要分配了記憶體沒有釋放,就會導致記憶體洩漏" -- 這是我以前的理解, 是片面的.
分配了的記憶體,如果它的指標沒有丟失,就不算是洩漏. 一般說來,為static指標變數或全域性的指標變數(它們的生存期是全域性的)進行記憶體分配,如果沒有釋放它,雖然這也是"not-freed blocks",但是它是"reachable"的.現代的os會得到這些指標並去釋放它.
下面是兩個例子:
1) 使用全域性指標或靜態指標:
int main()
使用valgrind檢查:
valgrind --leak-check=yes --show-reachable=yes -q ./memtest
==13764== searching for pointers to 1 not-freed blocks.
==13764== checked 4488448 bytes.
==13764==
==13764== 4 bytes in 1 blocks are still reachable in loss record 1 of 1
==13764== at 0xb74d27ab: __builtin_new (vg_replace_malloc.c:172)
==13764== by 0xb74d2802: operator new(unsigned) (vg_replace_malloc.c:185)
==13764== by 0x8048491: main (in /home/prog/valgrind/memtest)
==13764== by 0xb71c4ba6: __libc_start_main (in /lib/libc-2.3.2.so)
==13764==
==13764== leak summary:
==13764== definitely lost: 0 bytes in 0 blocks.
==13764== possibly lost: 0 bytes in 0 blocks.
==13764== still reachable: 4 bytes in 1 blocks.
==13764== suppressed: 0 bytes in 0 blocks.
==13764==
報告說有乙個"not-freed block",但這個block是reachable的,所以它不算是真正的memory leak.
2) 如果使用的是區域性指標:
int main()
==13782== searching for pointers to 1 not-freed blocks.
==13782== checked 4484352 bytes.
==13782==
==13782== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13782== at 0xb74d27ab: __builtin_new (vg_replace_malloc.c:172)
==13782== by 0xb74d2802: operator new(unsigned) (vg_replace_malloc.c:185)
==13782== by 0x8048491: main (in /home/prog/valgrind/memtest)
==13782== by 0xb71c4ba6: __libc_start_main (in /lib/libc-2.3.2.so)
==13782==
==13782== leak summary:
==13782== definitely lost: 4 bytes in 1 blocks.
==13782== possibly lost: 0 bytes in 0 blocks.
==13782== still reachable: 0 bytes in 0 blocks.
==13782== suppressed: 0 bytes in 0 blocks.
==13782==
報告說是"definitely lost",這才是真正的memory leak!
valgrind 記憶體洩露檢測
valgrind leak check full log file leak.log makefilevalgrind是乙個用於構建動態分析工具的儀器框架。valgrind工具可以自動檢測許多記憶體管理和執行緒錯誤，並詳細分析您的程式。valgrind可以執行非常詳細的分析，以幫助找到程式中的瓶頸。...
記憶體洩露檢測工具 valgrind
valgrind 安裝 2.解壓安裝包 tar jxvf valgrind 3.2.3.tar.bz2 3.解壓後生成目錄valgrind 3.2.3 4.cd valgrind 3.2.3 5.執行.autogen.sh設定環境 需要標準的autoconf工具 可選 6.configure 配置v...
valgrind 報告 ecpg記憶體洩露 二
真是原因到底是什麼呢？由於 exec sql connect 而導致 valgrind 報告 記憶體洩露錯誤。那麼在同乙個程式裡面，加入 exec sql disconnect 後，會如何呢？驗證的結果是，依然如此，還是會說 still reachable 220 bytes in 1 blocks...