内存检测工具valgrind

valgrind --tool=memcheck --leak-check=full --error-limit=no  --trace-children=yes  ./server

valgrind --tool=massif --trace-children=yes --time-unit=B --max-snapshots=100 --pages-as-heap=yes --detailed-freq=1000 --massif-out-file=a.out.massif.out.%p ./$server 2>>massif.log 1>&2 

valgrind --tool=massif --trace-children=yes --time-unit=B --max-snapshots=100  --massif-out-file=a.out.massif.out.%p ./$server 2>>massif.log 1>&2

ms_print massif.2222

Valgrind包括如下一些工具：

Memcheck。这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。这也是本文将重点介绍的部分。

Callgrind。它主要用来检查程序中函数调用过程中出现的问题。

Cachegrind。它主要用来检查程序中缓存使用出现的问题。

Helgrind。它主要用来检查多线程程序中出现的竞争问题。

Massif。它主要用来检查程序中堆栈使用中出现的问题。

Extension。可以利用core提供的功能，自己编写特定的内存调试工具。


 Memcheck 能够检测出内存问题，关键在于其建立了两个全局表。

Valid-Value 表：

对于进程的整个地址空间中的每一个字节(byte)，都有与之对应的 8 个 bits；对于 CPU 的每个寄存器，也有一个与之对应的 bit 向量。这些 bits 负责记录该字节或者寄存器值是否具有有效的、已初始化的值。

Valid-Address 表

对于进程整个地址空间中的每一个字节(byte)，还有与之对应的 1 个 bit，负责记录该地址是否能够被读写。

检测原理：

当要读写内存中某个字节时，首先检查这个字节对应的 A bit。如果该A bit显示该位置是无效位置，memcheck 则报告读写错误。

内核（core）类似于一个虚拟的 CPU 环境，这样当内存中的某个字节被加载到真实的 CPU 中时，该字节对应的 V bit 也被加载到虚拟的 CPU 环境中。一旦寄存器中的值，被用来产生内存地址，或者该值能够影响程序输出，则 memcheck 会检查对应的V bits，如果该值尚未初始化，则会报告使用未初始化内存错误。
 

Here’s the command line I used:

valgrind --smc-check=all --trace-children=yes --tool=massif --pages-as-heap=yes --detailed-freq=1000000 optg64/dist/bin/firefox -P cad20 -no-remote

Here’s what that means:

• --smc-check=all tells Valgrind that the program may use self-modifying code (or, in Firefox’s case, overwrite dynamically generated code).
• --trace-children tells Valgrind to trace into child processes exec’d by the program.  This is necessary because optg64/dist/bin/firefox is a wrapper script.
• --tool=massif tells Valgrind to run Massif.
• --pages-as-heap=yes tells Massif to profile allocations of all memory at the page level, rather than just profiling the heap (ie. memory allocated via malloc/new).  This is important because the heap is less than half of Firefox’s memory consumption.
• --detailed-freq=1000000 tells Massif to do detailed snapshots (which are more informative but more costly) only every 1,000,000th snapshot, which is less often than the default of every 10th snapshot.  This makes it run a bit faster.  This is fine because Massif always takes a detailed snapshot at the peak memory consumption point, and that’s the one I’m interested in.
• optg64/ is the name of my build directory.
• -P cad20 tells Firefox to use a particular profile that I set up appropriately.
• -no-remote tells Firefox to start a new instance;  this is necessary because I had a Firefox 3.6 process already running.

Massif produced a number of files, one per invoked process.  They have names like massif.out.22722, where the number is the process ID.  I worked out which one was the main Firefox executable;  this is not hard because the output file has the invoked command on its second line.  I then viewed it in two ways.  The first was with Massif’s ms_print script, using this command:

图形

 valgrind --tool=callgrind --separate-threads=yes ./server & 先用这货生产测试文件 

 

 然后用kcachegrind 打开 

http://sourceforge.net/projects/precompiledbin/?source=typ_redirect

KCacheGrind windows 系統下的代替方案
WinCacheGrind
可分析由xdebug產出的cachegrind.xxx檔，簡易版的kcachegrind。

windows port of kcachegrind
由原linux的kcachegrind，重新編譯在windows上可執行版，功能與linux kcachegrind相同。
Webgrind
網頁版的callgrind，搭配xdebug可做即時線上做php script profile。