㈠ c語言中的內存泄露 怎樣避免與檢測
堆經常會出現兩種類型的問題：1.釋放或改寫仍在使用的內存(稱為：「內存損壞」)。2.未釋放不再使用的內存(稱為：「內存泄露」)。這是最難被調試發現的問題之一
有些程序並不需要管理它們的動態內存的使用。當需要內存時，它們簡單地通過分配來獲得，從來不用擔心如何釋放它。這類程序包括編譯器和其他一些運行一段固定的（或有限的）時間然後終止的程序。當這種類型的程序終止時，所有內存會被自動回收。細心查驗每塊內存是否需要回收純屬浪費時間，因為它們不會再被使用。
其他程序的生存時間要長一點。有些工具如日歷管理器、郵件工具以及操作系統本事經常需要數日及至數周連續運行，並需要管理動態內存的分配和回收。由於C語言通常並不使用垃圾回收器（自動確認並回收不再使用的內存塊），這些C程序在使用malloc()和free()時不得不非常慎重。
堆經常會出現兩種類型的問題：
1.釋放或改寫仍在使用的內存(稱為：「內存損壞」)。
2.未釋放不再使用的內存(稱為：「內存泄露」)。
這是最難被調試發現的問題之一。如果每次已分配的內存塊不再使用而程序並不釋放它們，進程就會一邊分配越來越多的內存，一邊卻並不釋放不再使用的那部分內存。
避免內存泄露
每當調用malloc分配內存時，注意在以後要調用相應的free來釋放它。
如果不知道如何調用free與先前的malloc相對應，那麼很可能已經造成了內存泄露！
一種簡單的方法就是在可能的時候使用alloca()來分配動態內存，以避免上述情況。當離開調用alloca的函數時，它所分配的內存會被自動釋放。
顯然，這並不適用於那些比創建它們的函數生命期更長的結構。但如果對象的生命期在該函數結束前便已經終止，這種建立在堆棧上的動態內存分配是一種開銷很小的選擇。有些人不提倡使用alloca，因為它並不是以後總可移植的方法。如果處理器在硬體上不支持堆棧，alloca()就很難高效地實現。
我們使用「內存泄露」這個詞是因為一種稀有的資源正在被一個進程榨乾。內存泄露的主要可見症狀就是罪魁進程的速度很減慢。原因是體積大的進程更有可能被系統換出，讓別的進程運行，而且大的進程在換進換出時花費的時間也更多。即使泄露的內存本省並不被引用，但它仍用可能存在於頁面中（內容自然是垃圾），這樣就增加了進程的工作頁數量，降低了性能。另外需要注意的一點是，內存泄露往往比忘記釋放的的數據結構要打，因為malloc()所分配的內存通常會圓整為下一個大於申請數量的2的整數次方（如申請212B,會圓整為256B）。在資源有限的情況下，即使引起內存泄露的進程並不運行，整個系統運行速度也會被拖慢。從理論上說，進程的大小有一個上限值，這在不同的操作系統中各不相同。在當前的SunOS版本中，進程的最大地址空間可以多達4GB。事實上，在進程所泄露的內存遠未達到這個數量時，磁碟的交換區早已消耗殆盡。
如何檢測內存泄露
觀察內存泄露是一個兩步驟的過程。首先，使用swap命令觀察還有多少可用的交換空間：
/usr/sbin/swap -s
total:17228K bytes allocated + 5396K reserved=22626K used，29548K available.
在一兩分鍾內鍵入該命令三到四次，看看可用的交換區是否在減少。還可以使用其他一些/usr/bin/*stat工具如netstat、vmstat等。如發現波段有內存被分配且從不釋放，一個可能的解釋就是有個進程出現了內存泄露。
㈡ linux c 內存泄露怎麼測試
是不是說沒有一種內存檢查工具能夠在linux使用呢，也不是，像valgrind工具還是相當不錯的。他的下載地址是 下載一個valgrind 3.2.3 (tar.bz2) 工具，按照裡面的README提示，安裝後就可以使用這個工具來檢測內存泄露和內存越界等。這是一個沒有界...
㈢ C語言中，怎麼檢查調用一個函數之後，有無內存泄露
如果這個函數是你寫的 那最好的方法 就是檢查代碼
如果不是
那麼 可以自己做一個C庫
把malloc和free改一下名字
然後 你再自己實現一個malloc 和free
這樣就可以記錄申請和釋放的數量
得到是否有泄露了
㈣ C語言中內存泄漏的源碼
內存泄漏一般是指:程序動態分配的堆內存在使用完後沒有被釋放.有兩類內存泄漏情況:一.在ring3下內存泄漏(臨時性的ring0內存泄漏);二.在ring0下內存泄漏.前者的一般不會造成嚴重問題,頂多程序卡死,當進程終止,所有該進程的內存泄漏隨之變得無意義.而後者則會造成系統卡死甚至倒塌.至於c程序,不言自明.
㈤ 高分求助！！！C內存泄露檢測問題
你可以對於malloc進行overload，
在malloc中，進行bufferID，Appchain等信息的輸出
㈥ JNI程序如何檢測C代碼的內存泄漏
經過測試，memwatch就可以直接用於JNI中的C代碼的內存檢測。程序在JNI調用後，就會在目錄下生成一個文件，裡面記錄了內存數據。
結論：JNI中C代碼的內存檢測和單純的C代碼的內存檢測沒什麼不同，不需要做特殊處理。
㈦ c語言內存泄漏如何定位
用gstack長期觀察函數調用棧，分析調用情況與內存增長的關系，找到與內存泄露相關的函數，重點分析。
C語言是一門面向過程的、抽象化的通用程序設計語言，廣泛應用於底層開發。C語言能以簡易的方式編譯、處理低級存儲器。C語言是僅產生少量的機器語言以及不需要任何運行環境支持便能運行的高效率程序設計語言。
盡管C語言提供了許多低級處理的功能，但仍然保持著跨平台的特性，以一個標准規格寫出的C語言程序可在包括類似嵌入式處理器以及超級計算機等作業平台的許多計算機平台上進行編譯。
C語言是一門面向過程的計算機編程語言，與C++、C#、Java等面向對象編程語言有所不同。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、僅產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。
C語言描述問題比匯編語言迅速、工作量小、可讀性好、易於調試、修改和移植，而代碼質量與匯編語言相當。C語言一般只比匯編語言代碼生成的目標程序效率低10%-20%。因此，C語言可以編寫系統軟體。
㈧ 在Linux中運行的C程序出現內存泄漏現象，怎麼解決
內存泄漏指由於疏忽或錯誤造成程序未能釋放已經不再使用的內存的情況。內存泄漏並非指內存在物理上的消失，而是應用程序分配某段內存後，由於設計錯誤，失去了對該段內存的控制，因而造成了內存的浪費。
可以使用相應的軟體測試工具對軟體進行檢測。
1. ccmalloc－Linux和Solaris下對C和C++程序的簡單的使用內存泄漏和malloc調試庫。
2. Dmalloc－Debug Malloc Library.
3. Electric
Fence－Linux分發版中由Bruce Perens編寫的malloc()調試庫。
4. Leaky－Linux下檢測內存泄漏的程序。
5. LeakTracer－Linux、Solaris和HP-UX下跟蹤和分析C++程序中的內存泄漏。
6. MEMWATCH－由Johan
Lindh編寫，是一個開放源代碼C語言內存錯誤檢測工具，主要是通過gcc的precessor來進行。
7. Valgrind－Debugging and profiling Linux programs, aiming at
programs written in C and C++.
8. KCachegrind－A visualization tool for the profiling data
generated by Cachegrind and Calltree.
9. Leak
Monitor－一個Firefox擴展，能找出跟Firefox相關的泄漏類型。
10. IE Leak Detector
(Drip/IE Sieve)－Drip和IE Sieve leak
detectors幫助網頁開發員提升動態網頁性能通過報告可避免的因為IE局限的內存泄漏。
11. Windows Leaks
Detector－探測任何Win32應用程序中的任何資源泄漏(內存，句柄等)，基於Win API調用鉤子。
12. SAP Memory
Analyzer－是一款開源的JAVA內存分析軟體，可用於輔助查找JAVA程序的內存泄漏，能容易找到大塊內存並驗證誰在一直佔用它，它是基於Eclipse
RCP(Rich Client Platform)，可以下載RCP的獨立版本或者Eclipse的插件。
13. DTrace－即動態跟蹤Dynamic
Tracing，是一款開源軟體，能在Unix類似平台運行，用戶能夠動態檢測操作系統內核和用戶進程，以更精確地掌握系統的資源使用狀況，提高系統性能，減少支持成本，並進行有效的調節。
14. IBM Rational PurifyPlus－幫助開發人員查明C/C++、託管.NET、Java和VB6代碼中的性能和可靠性錯誤。PurifyPlus
將內存錯誤和泄漏檢測、應用程序性能描述、代碼覆蓋分析等功能組合在一個單一、完整的工具包中。
15. Parasoft Insure++－針對C/C++應用的運行時錯誤自動檢測工具，它能夠自動監測C/C++程序，發現其中存在著的內存破壞、內存泄漏、指針錯誤和I/O等錯誤。並通過使用一系列獨特的技術（SCI技術和變異測試等），徹底的檢查和測試我們的代碼，精確定位錯誤的准確位置並給出詳細的診斷信息。能作為Microsoft
Visual C++的一個插件運行。
16. Compuware DevPartner for Visual C++ BoundsChecker
Suite－為C++開發者設計的運行錯誤檢測和調試工具軟體。作為Microsoft Visual Studio和C++ 6.0的一個插件運行。
17. Electric Software GlowCode－包括內存泄漏檢查，code
profiler，函數調用跟蹤等功能。給C++和.Net開發者提供完整的錯誤診斷，和運行時性能分析工具包。
18. Compuware DevPartner Java
Edition－包含Java內存檢測,代碼覆蓋率測試,代碼性能測試,線程死鎖,分布式應用等幾大功能模塊。
19. Quest JProbe－分析Java的內存泄漏。
20. ej-technologies JProfiler－一個全功能的Java剖析工具，專用於分析J2SE和J2EE應用程序。它把CPU、執行緒和內存的剖析組合在一個強大的應用中。JProfiler可提供許多IDE整合和應用伺服器整合用途。JProfiler直覺式的GUI讓你可以找到效能瓶頸、抓出內存泄漏、並解決執行緒的問題。4.3.2注冊碼：A-G666#76114F-1olm9mv1i5uuly#0126
21. BEA JRockit－用來診斷Java內存泄漏並指出根本原因，專門針對Intel平台並得到優化，能在Intel硬體上獲得最高的性能。
22. SciTech Software AB .NET Memory
Profiler－找到內存泄漏並優化內存使用針對C#，VB.Net，或其它.Net程序。
23. YourKit .NET & Java Profiler－業界領先的Java和.NET程序性能分析工具。
24. AutomatedQA AQTime－AutomatedQA的獲獎產品performance profiling和memory
debugging工具集的下一代替換產品，支持Microsoft, Borland, Intel, Compaq 和
GNU編譯器。可以為.NET和Windows程序生成全面細致的報告，從而幫助您輕松隔離並排除代碼中含有的性能問題和內存/資源泄露問題。支持.Net
1.0,1.1,2.0,3.0和Windows 32/64位應用程序。
25. JavaScript Memory Leak Detector－微軟全球產品開發歐洲團隊(Global Proct
Development- Europe team, GPDE)
發布的一款調試工具，用來探測JavaScript代碼中的內存泄漏，運行為IE系列的一個插件。
㈨ C語言指針 內存泄漏
for (i=0;i<10;i++)
{
char *p=(char *)malloc(nSize *sizeof(char));
i++;
}
調用了10次malloc，就分配了10份空間，每次循環，你之前分配空間的地址都會被新一次分配的地址覆蓋，繼而丟失了。
最後你只是釋放了一次，也就是9次都丟失了，造成內存泄露
㈩ 如何使用工具進行C/C++的內存泄漏檢測
Memcheck是一個內存錯誤檢測器。它有助於使你的程序，尤其是那些用C和C++寫的程序，更加准確。Cachegrind是一個緩存和分支預測分析器。它有助於使你的程序運行更快。Callgrind是一個調用圖緩存生成分析器。它與Cachegrind的功能有重疊，但也收集Cachegrind不收集的一些信息Helgrind是一個線程錯誤檢測器。它有助於使你的多線程程序更加准確。DRD也是一個線程錯誤檢測器。它和Helgrind相似，但使用不同的分析技術，所以可能找到不同的問題。Massif是一個堆分析器。它有助於使你的程序使用更少的內存。DHAT是另一種不同的堆分析器。它有助於理解塊的生命期、塊的使用和布局的低效等問題。SGcheck是一個實驗工具，用來檢測堆和全局數組的溢出。它的功能和Memcheck互補：SGcheck找到Memcheck無法找到的問題，反之亦然。BBV是個實驗性質的SimPoint基本塊矢量生成器。它對於進行計算機架構的研究和開發很有用處。
系統編程中一個重要的方面就是有效地處理與內存相關的問題。你的工作越接近系統，你就需要面對越多的內存問題。有時這些問題非常瑣碎，而更多時候它會演變成一個調試內存問題的惡夢。所以，在實踐中會用到很多工具來調試內存問題。
在本文中，我們將討論最流行的開源內存管理框架 VALGRIND。
摘自 Valgrind.org：
Valgrind是用於構建動態分析工具的探測框架。它包括一個工具集，每個工具執行某種類型的調試、分析或類似的任務，以幫助完善你的程序。Valgrind的架構是模塊化的，所以可以容易地創建新的工具而又不會擾亂現有的結構。
許多有用的工具被作為標准而提供。
Memcheck是一個內存錯誤檢測器。它有助於使你的程序，尤其是那些用C和C++寫的程序，更加准確。
Cachegrind是一個緩存和分支預測分析器。它有助於使你的程序運行更快。
Callgrind是一個調用圖緩存生成分析器。它與Cachegrind的功能有重疊，但也收集Cachegrind不收集的一些信息。
Helgrind是一個線程錯誤檢測器。它有助於使你的多線程程序更加准確。
DRD也是一個線程錯誤檢測器。它和Helgrind相似，但使用不同的分析技術，所以可能找到不同的問題。
Massif是一個堆分析器。它有助於使你的程序使用更少的內存。
DHAT是另一種不同的堆分析器。它有助於理解塊的生命期、塊的使用和布局的低效等問題。
SGcheck是一個實驗工具，用來檢測堆和全局數組的溢出。它的功能和Memcheck互補：SGcheck找到Memcheck無法找到的問題，反之亦然。
BBV是個實驗性質的SimPoint基本塊矢量生成器。它對於進行計算機架構的研究和開發很有用處。
也有一些對大多數用戶沒有用的小工具：Lackey是演示儀器基礎的示例工具；Nulgrind是一個最小化的Valgrind工具，不做分析或者操作，僅用於測試目的。
在這篇文章我們將關注「memcheck」工具。
使用 Valgrind Memcheck
memcheck工具的使用方式如下:
valgrind --tool=memcheck ./a.out
從上面的命令可以清楚的看到, 主要的命令是valgrind，而我們想使用的工具是通過'-tool'選項來指定的. 上面的『a.out』指的是我們想使用memcheck運行的可執行文件.
該工具可以檢測下列與內存相關的問題 :
未釋放內存的使用
對釋放後內存的讀/寫
對已分配內存塊尾部的讀/寫
內存泄露
不匹配的使用malloc/new/new[] 和 free/delete/delete[]
重復釋放內存
注意: 上面列出的並不很全面，但卻包含了能被該工具檢測到的很多普遍的問題.
讓我們一個一個地對上面的場景進行討論:
注意: 下面討論的所有測試代碼都應該使用gcc並且加上-g選項(用來在memcheck的輸出中生成行號)進行編譯. 就想我們之前討論過的 C程序被編譯成可執行文件, 它需要經歷四個不同的階段.
1. 使用未初始化的內存
Code :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p;
char c = *p;
printf("\n [%c]\n",c);
return 0;
}
在上面的代碼中，我們嘗試使用未初始化的指針 『p』.
讓我們運行Memcheck來看下結果.
$ valgrind --tool=memcheck ./val
==2862== Memcheck, a memory error detector
==2862== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2862== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2862== Command: ./val
==2862==
==2862== Use of uninitialised value of size 8
==2862== at 0x400530: main (valgrind.c:8)
==2862==
[#]
==2862==
==2862== HEAP SUMMARY:
==2862== in use at exit: 0 bytes in 0 blocks
==2862== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2862==
==2862== All heap blocks were freed -- no leaks are possible
==2862==
==2862== For counts of detected and suppressed errors, rerun with: -v
==2862== Use --track-origins=yes to see where uninitialized values come from
==2862== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
從上面的輸出可以看到,Valgrind檢測到了未初始化的變數，然後給出了警告(上面加粗的幾行(譯者註：貌似上面沒有加粗的)).
2. 在內存被釋放後進行讀/寫
Code :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = malloc(1);
*p = 'a';
char c = *p;
printf("\n [%c]\n",c);
free(p);
c = *p;
return 0;
}
上面的代碼中，我們有一個釋放了內存的指針 『p』 然後我們又嘗試利用指針獲取值.
讓我們運行memcheck來看一下Valgrind對這種情況是如何反應的.
$ valgrind --tool=memcheck ./val
==2849== Memcheck, a memory error detector
==2849== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2849== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2849== Command: ./val
==2849==
[a]
==2849== Invalid read of size 1
==2849== at 0x400603: main (valgrind.c:30)
==2849== Address 0x51b0040 is 0 bytes inside a block of size 1 free'd
==2849== at 0x4C270BD: free (vg_replace_malloc.c:366)
==2849== by 0x4005FE: main (valgrind.c:29)
==2849==
==2849==
==2849== HEAP SUMMARY:
==2849== in use at exit: 0 bytes in 0 blocks
==2849== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==2849==
==2849== All heap blocks were freed -- no leaks are possible
==2849==
==2849== For counts of detected and suppressed errors, rerun with: -v
==2849== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
從上面的輸出內容可以看到，Valgrind檢測到了無效的讀取操作然後輸出了警告 『Invalid read of size 1′.
另注,使用gdb來調試c程序.
3. 從已分配內存塊的尾部進行讀/寫
Code :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = malloc(1);
*p = 'a';
char c = *(p+1);
printf("\n [%c]\n",c);
free(p);
return 0;
}
在上面的代碼中，我們已經為『p』分配了一個位元組的內存,但我們在將值讀取到 『c』中的時候使用的是地址p+1.
現在我們使用Valgrind運行上面的代碼 :
$ valgrind --tool=memcheck ./val
==2835== Memcheck, a memory error detector
==2835== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2835== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2835== Command: ./val
==2835==
==2835== Invalid read of size 1
==2835== at 0x4005D9: main (valgrind.c:25)
==2835== Address 0x51b0041 is 0 bytes after a block of size 1 alloc'd
==2835== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2835== by 0x4005C5: main (valgrind.c:22)
==2835==
[]
==2835==
==2835== HEAP SUMMARY:
==2835== in use at exit: 0 bytes in 0 blocks
==2835== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==2835==
==2835== All heap blocks were freed -- no leaks are possible
==2835==
==2835== For counts of detected and suppressed errors, rerun with: -v
==2835== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
同樣，該工具在這種情況下也檢測到了無效的讀取操作.
4. 內存泄露
Code:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = malloc(1);
*p = 'a';
char c = *p;
printf("\n [%c]\n",c);
return 0;
}
在這次的代碼中, 我們申請了一個位元組但是沒有將它釋放.現在讓我們運行Valgrind看看會發生什麼：
$ valgrind --tool=memcheck --leak-check=full ./val
==2888== Memcheck, a memory error detector
==2888== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2888== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2888== Command: ./val
==2888==
[a]
==2888==
==2888== HEAP SUMMARY:
==2888== in use at exit: 1 bytes in 1 blocks
==2888== total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==2888==
==2888== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2888== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2888== by 0x400575: main (valgrind.c:6)
==2888==
==2888== LEAK SUMMARY:
==2888== definitely lost: 1 bytes in 1 blocks
==2888== indirectly lost: 0 bytes in 0 blocks
==2888== possibly lost: 0 bytes in 0 blocks
==2888== still reachable: 0 bytes in 0 blocks
==2888== suppressed: 0 bytes in 0 blocks
==2888==
==2888== For counts of detected and suppressed errors, rerun with: -v
==2888== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
輸出行(上面加粗的部分)顯示，該工具能夠檢測到內存的泄露.
注意: 在這里我們增加了一個選項『–leak-check=full』來得到內存泄露的詳細細節.
5. 不匹配地使用malloc/new/new[] 和 free/delete/delete[]
Code:
#include <stdio.h>
#include <stdlib.h>
#include<iostream>
int main(void)
{
char *p = (char*)malloc(1);
*p = 'a';
char c = *p;
printf("\n [%c]\n",c);
delete p;
return 0;
}
上面的代碼中，我們使用了malloc()來分配內存，但是使用了delete操作符來刪除內存.
注意 : 使用g++來編譯上面的代碼，因為delete操作符是在C++中引進的，而要編譯C++需要使用g++.
讓我們運行來看一下 :
$ valgrind --tool=memcheck --leak-check=full ./val
==2972== Memcheck, a memory error detector
==2972== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2972== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2972== Command: ./val
==2972==
[a]
==2972== Mismatched free() / delete / delete []
==2972== at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)
==2972== by 0x40080B: main (valgrind.c:13)
==2972== Address 0x595e040 is 0 bytes inside a block of size 1 alloc'd
==2972== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2972== by 0x4007D5: main (valgrind.c:7)
==2972==
==2972==
==2972== HEAP SUMMARY:
==2972== in use at exit: 0 bytes in 0 blocks
==2972== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==2972==
==2972== All heap blocks were freed -- no leaks are possible
==2972==
==2972== For counts of detected and suppressed errors, rerun with: -v
==2972== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
從上面的輸出可以看到 (加粗的行), Valgrind清楚的說明了『不匹配的使用了free() / delete / delete []『
你可以嘗試在測試代碼中使用'new'和'free'進行組合來看看Valgrind給出的結果是什麼.
6. 兩次釋放內存
Code :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = (char*)malloc(1);
*p = 'a';
char c = *p;
printf("\n [%c]\n",c);
free(p);
free(p);
return 0;
}
在上面的代碼中, 我們兩次釋放了'p'指向的內存. 現在讓我們運行memcheck :
$ valgrind --tool=memcheck --leak-check=full ./val
==3167== Memcheck, a memory error detector
==3167== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3167== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==3167== Command: ./val
==3167==
[a]
==3167== Invalid free() / delete / delete[]
==3167== at 0x4C270BD: free (vg_replace_malloc.c:366)
==3167== by 0x40060A: main (valgrind.c:12)
==3167== Address 0x51b0040 is 0 bytes inside a block of size 1 free'd
==3167== at 0x4C270BD: free (vg_replace_malloc.c:366)
==3167== by 0x4005FE: main (valgrind.c:11)
==3167==
==3167==
==3167== HEAP SUMMARY:
==3167== in use at exit: 0 bytes in 0 blocks
==3167== total heap usage: 1 allocs, 2 frees, 1 bytes allocated
==3167==
==3167== All heap blocks were freed -- no leaks are possible
==3167==
==3167== For counts of detected and suppressed errors, rerun with: -v
==3167== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
從上面的輸出可以看到(加粗的行), 該功能檢測到我們對同一個指針調用了兩次釋放內存操作.