 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
bzip2使用手册(英文)
下载积分：900
内容提示：bzip2使用手册(英文)
文档格式：PDF|
浏览次数：14|
上传日期： 23:30:22|
文档星级：
全文阅读已结束，如果下载本文需要使用
 900 积分
下载此文档
该用户还上传了这些文档
bzip2使用手册(英文)
官方公共微信Open Source Awards 2004: Julian Seward for Valgrind - TechRepublic
If you've done any real programming, sooner or later you're going to find yourself in need of a good debugger. There's only so much you can do by inserting printf() statements to spit out bits of debug text—eventually you have to roll up your sleeves and break out the debugger.For the x86/Linux world, you could of course use good old , which should be part of almost any Linux distribution. The thing is, gdb is most useful when you know there's a particular bug you're trying to track down. But it's the bugs you don't know about that come back to haunt you, because inevitably it's one of your customers who runs into the bug after you've shipped. That's where something like Julian Seward's
comes into play.Read more about the winners of the 2004 Open Source Awards:
Valgrind is essentially an emulator: It creates an imaginary x86 environment where your program runs, and can report on any x86 activity, such as memory allocation and cache hits. In fact, you can use it in conjunction with gdb—once Valgrind identifies a problem, you can have it attach gdb at that point in your program to figure out exactly what is going on inside your application.Jeremy Allison, one of the lead developers on Samba and a member of the Open Source Awards nominating committee, calls Valgrind "a pretty amazing piece of work." He speaks from experience because his Samba team used Valgrind to help optimize Samba 3.0, averaging about a 15-percent performance improvement.In the interest of full disclosure, we should note that CNET uses Valgrind. Ron Rothman, a Senior Software Engineer at CNET, says that "Valgrind on Linux is roughly comparable to Purify on Solaris." High praise indeed given that Purify sells for thousands of dollars per seat license, which puts it out of reach even for many commercial developers.We recently conducted an e-mail interview with Julian, who lives across the pond in England.<: What prompted you to create Valgrind?Seward: When I was a grad student around 1992, I came across Purify on SPARC-Solaris and thought it was an amazing tool. Time passed, 1996 came and so did cheap x86 boxes running Linux (I remember starting with kernel 1.0.4). gcc, gdb, X—Linux had most stuff for free, but there was no equivalent of Purify. The closest I saw was a system called
by Tristan Gingold.I wound up with a job working on the
(GHC), which is a fabulous compiler for a fabulous programming language &/shameless plug&. One of the major parts of GHC I worked on was the back-end x86 and SPARC code generators, and the register allocator. From this I learnt a lot about the x86 instruction set and code generation techniques, and the idea of making a memory-checking tool for Linux came back into view. There followed almost three years of spare-time messing around prior to the first Valgrind release (1.0.0) in June 2002.Valgrind's design draws inspiration from various sources. In the early '90s, Sun released a dynamic translation-based user-space emulator called , which is where I got the dynamic-translation idea. Some other technical ideas came from GHC. Last but not least, Chris Fraser and David Hanson did a simple, small, elegant, retargetable compiler,
about it. Their approach was to shoot for getting 80 percent of the performance for 20 percent of the complexity. I admire the way they have very carefully designed lcc to reduce the implementation burden to something two people could manage. This is a concept I tried to emulate in Valgrind.<: What does the name stand for? We thought it might be "value grinder."Seward: A lot of people think that, reasonably enough, but not so. The name comes from Nordic mythology. Originally (before release) the project was called , who was the watchman of the (Nordic) gods. He could "see a hundred miles by day or night, hear the grass growing, see the wool growing on a sheep's back" (etc). This would be an excellent name for a tool like Valgrind. Unfortunately, the name was already taken by a security package "" and so I didn't use it.Eventually my partner Donna Robinson uncovered the Nordic name Valgrind, which is the main entrance to . Over it stand three guardians: a wolf, a boar, and an eagle. These guardians will not allow anyone judged unworthy to pass through, which is the part that sold the name to us. Although not as good as Heimdall, the name stuck. Around that time we got a cat and named him Heimdall instead.<: Where do you work?Seward: I'm a compiler-writer at
in Cambridge, UK.<: I see you've written a number of research papers—could you tell us about your research interests?Seward: My long-term interests are tools and techniques for making more reliable software. Many programmers seem obsessed with performance, to the detriment of correctness, simplicity, modularity, and maintainability. Valgrind is only useful because C and C++ are such crappy programming languages.<: How do those interests tie into your work on Valgrind? Specifically, I'm curious if you've used Haskell to create Valgrind, or is it in some more traditional language like C? Or the other way around—have you used Valgrind in doing any of your Haskell development?Seward: Unfortunately, Valgrind is entirely in C. Valgrind and the program it is running have to share the same address space, so we cannot use any of the standard libraries—not even glibc—in Valgrind. That rules out more complex languages. We're investigating ways to better insulate Valgrind from the program being run. That work will allow us to write Valgrind in any language we please. I'd like to move to C++, for the usual reasons that people use C++.It would be great to write at least some of V in Haskell, or another language which is strong at symbolic computation. Currently, though, Haskell implementations cannot compile Haskell code into a library that is sufficiently self-contained for use inside Valgrind. Also, they aren't portable enough: It would require a Haskell compiler on every platform for which we want V to work in the future.<: Are you at the point now with Valgrind that you can bootstrap? That is, can you run Valgrind to help debug and analyze Valgrind itself?Seward: No, not yet. We're moving in that direction, and it's definitely on our long-term roadmap. It should fall out naturally from other structural changes we hope to do. As the thing grows ever bigger, we more and more would like to valgrindify Valgrind, and it's a pain not being able to at present.<: What tools do you use when working on Valgrind?Seward: Well, not much, really. It's all very traditional: emacs + make + gcc and occasionally gdb if it crashes. Although gdb-ingValgrind can be a confusing experience, since you've got a mixture of Valgrind and some other program running at the same time.<: Are there methodologies, coding styles, a favorite beverage, anything like that which you find most useful in your day-to-day coding?Seward: Paranoia, careful design, lots of assertions, internal sanity checks, comment as much as possible. About a year ago Nick Nethercote added a regression test system, and that's been a big help.Valgrind is loaded with assertion checks and internal sanity checkers which periodically inspect critical data structures. These are permanently enabled. I don't care if 5 percent or even 10 percent of the total run-time is spent in these checks—automated debugging is the way to go. As a result, Valgrind almost never segfaults—instead it emits some kind of a useful error message before dying. That's something I'm rather proud of.<: What would you say to an IT manager who's trying to decide whether to use Valgrind versus a commercial product like Purify, or one of the other open-source tools like mpatrol or Electric Fence?Seward: Well, if your app runs on x86-Linux, you haven't got much to lose trying Valgrind: You don't need to recompile your app, just try it. You can probably establish if V is going to be helpful, or not, inside an hour. And if it is helpful, you may save yourself days of debugging time.What we see is that most non-trivial C/C++ applications have memory management bugs of some kind. If you haven't Valgrinded your code before, do so now. If it finds nothing, you haven't wasted much time. If it points out problems, you may be able to fix bugs which might otherwise be crashes experienced by your customers.The OpenOffice/StarOffice developers recently ValgrindedOOo, which is a huge C++ application by anybody's standards. They wrote a
of their experiences, worth a read.<: Any particular people you'd like to thank or recognize for their contributions to Valgrind?Seward: Definitely. This is a team effort, and V would be a mere shadow of its current self without the work of others, but particularly that of Nick Nethercote and Jeremy Fitzhardinge, both of whom have put immense amounts of effort into the project.The
development folks endured many pre-release snapshots, and continue to contribute numerous enhancements. KDE 3.0 was the first big project to be Valgrindified. Their feedback and support has been very valuable.Last but not least, a big thank-you to Donna Robinson for creating an environment in which Valgrind could come into existence.
Tech News You Can Use
We deliver the top business tech news stories about the companies, the people, and the products revolutionizing the planet.
Delivered Daily
Best of the Week
Our editors highlight the TechRepublic articles, galleries, and videos that you absolutely cannot miss to stay current on the latest IT news, innovations, and tips.
Delivered FridaysC/C++开发工具（12）
Valgrind使用说明
&&&&Valgrind是运行在Linux上一套基于仿真技术的程序调试和分析工具，是公认的最接近Purify的产品，它包含一个内核——一个软件合成的CPU，和一系列的小工具，每个工具都可以完成一项任务——调试，分析，或测试等。Valgrind可以检测内存泄漏和内存越界，还可以分析cache的使用等，灵活轻巧而又强大。&&&&
一&Valgrind概观
Valgrind的最新版是3.2.3，该版本包含下列工具：
&&&&1、memcheck：检查程序中的内存问题，如泄漏、越界、非法指针等。
&&&&2、callgrind：检测程序代码覆盖，以及分析程序性能。
&&&&3、cachegrind：分析CPU的cache命中率、丢失率，用于进行代码优化。
&&&&4、helgrind：用于检查多线程程序的竞态条件。
&&&&5、massif：堆栈分析器，指示程序中使用了多少堆内存等信息。
&&&&6、lackey：
&&&&&&&7、nulgrind：
二&Valgrind工具详解
1.Memcheck
&&&&最常用的工具，用来检测程序中出现的内存问题，所有对内存的读写都会被检测到，一切对malloc、free、new、delete的调用都会被捕获。所以，它能检测以下问题：
&&&&&&&1、对未初始化内存的使用；
&&&&&&&2、读/写释放后的内存块；
&&&&&&&3、读/写超出malloc分配的内存块；
&&&&&&&4、读/写不适当的栈中内存块；
&&&&&&&5、内存泄漏，指向一块内存的指针永远丢失；
&&&&&&&6、不正确的malloc/free或new/delete匹配；
&&&&&&&7、memcpy()相关函数中的dst和src指针重叠。
这些问题往往是C/C&#43;&#43;程序员最头疼的问题，Memcheck能在这里帮上大忙。
2.Callgrind
&&&&和gprof类&#20284;的分析工具，但它对程序的运行观察更是入微，能给我们提供更多的信息。和gprof不同，它不需要在编译源代码时附加特殊选项，但加上调试选项是推荐的。Callgrind收集程序运行时的一些数据，建立函数调用关系图，还可以有选择地进行cache模拟。在运行结束时，它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。
&&&&说明：这个工具我也没有用会，网上基本没有找到有指导性的文档，暂时留在后面慢慢研究吧。
3.Cachegrind
&&&&&&&Cache分析器，它模拟CPU中的一级缓存I1，Dl和二级缓存，能够精确地指出程序中cache的丢失和命中。如果需要，它还能够为我们提供cache丢失次数，内存引用次数，以及每行代码，每个函数，每个模块，整个程序产生的指令数。这对优化程序有很大的帮助。
&&&&作一下广告：valgrind自身利用该工具在过去几个月内使性能提高了25%-30%。据早先报道，kde的开发team也对valgrind在提高kde性能方面的帮助表示感谢。
4.Helgrind
&&&&它主要用来检查多线程程序中出现的竞争问题。Helgrind寻找内存中被多个线程访问，而又没有一贯加锁的区域，这些区域往往是线程之间失去同步的地方，而且会导致难以发掘的错误。Helgrind实现了名为“Eraser”的竞争检测算法，并做了进一步改进，减少了报告错误的次数。不过，Helgrind仍然处于实验阶段。
&&&&堆栈分析器，它能测量程序在堆栈中使用了多少内存，告诉我们堆块，堆管理块和栈的大小。Massif能帮助我们减少内存的使用，在带有虚拟内存的现代系统中，它还能够加速我们程序的运行，减少程序停留在交换区中的几率。
&&&&&&&Massif对内存的分配和释放做profile。程序开发者通过它可以深入了解程序的内存使用行为，从而对内存使用进行优化。这个功能对C&#43;&#43;尤其有用，因为C&#43;&#43;有很多隐藏的内存分配和释放
此外，lackey和nulgrind也会提供。Lackey是小型工具，很少用到；Nulgrind只是为开发者展示如何创建一个工具。我们就不做介绍了。
三&使用Valgrind
&&&&&&&Valgrind使用起来非常简单，你甚至不需要重新编译你的程序就可以用它。当然如果要达到最好的效果，获得最准确的信息，还是需要按要求重新编译一下的。比如在使用memcheck的时候，最好关闭优化选项。
&&&&&&&valgrind命令的&#26684;式如下：
&&&&&&&valgrind&[valgrind-options] your-prog [your-prog options]
一些常用的选项如下：
显示帮助信息。
显示valgrind内核的版本，每个工具都有各自的版本。
-q --quiet
安静地运行，只打印错误信息。
-v --verbose
打印更详细的信息。
--tool=&toolname& [default: memcheck]
最常用的选项。运行valgrind中名为toolname的工具。如果省略工具名，默认运行memcheck。
--db-attach=&yes|no& [default: no]
绑定到调试器上，便于调试错误。
1、检测内存泄漏
&&&&示例代码如下：
#include &stdlib.h&
#include &stdio.h&
int main(void)
&&&&&&&char *
&&&&&&&ptr = (char *)malloc(10);
&&&&&&&return 0;
保存为memleak.c并编译，然后用valgrind检测。
$ gcc -o memleak memleak.c
（valgrind和purify最大的不同在于：valgrind只接管程序执行的过程，编译时不需要valgrind干预，而purify会干预程序编译过程）
$&valgrind&--tool=memcheck ./memleak
我们得到如下错误信息：
[konten@tencent test_valgrind]$ valgrind&./memleak
==29646== Memcheck, a memory error detector.
==29646== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29646== Using LibVEX rev 1732, a library for dynamic binary translation.
==29646== Copyright (C) , and GNU GPL'd, by OpenWorks LLP.
==29646== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==29646== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29646== For more details, rerun with: -v
==29646== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==29646== malloc/free: in use at exit: 10 bytes in 1 blocks.&&&//指示在程序退出时，还有多少内存没有释放。
==29646== malloc/free: 1 allocs, 0 frees, 10 bytes allocated.&//&指示该执行过程malloc和free调用的次数。
==29646== For counts of detected errors, rerun with: -v&//&提示如果要更详细的信息，用-v选项。
==29646== searching for pointers to 1 not-freed blocks.
==29646== checked 56,164 bytes.
==29646== LEAK SUMMARY:
==29646==&&&&definitely lost: 10 bytes in 1 blocks.
==29646==&&&&&&possibly lost: 0 bytes in 0 blocks.
==29646==&&&&still reachable: 0 bytes in 0 blocks.
==29646==&&&&&&&&&suppressed: 0 bytes in 0 blocks.
==29646== Rerun with --leak-check=full to see details of leaked memory.
[konten@tencent test_valgrind]$
以上结果中，红色的是手工添加的说明信息，其他是valgrind的输出。可以看到，如果我们仅仅用默认方式执行，valgrind只报告内存泄漏，但没有显示具体代码中泄漏的地方。
&&&&&&&因此我们需要使用&“--leak-check=full”选项启动&valgrind，我们再执行一次：
[konten@tencent test_valgrind]$ valgrind --leak-check=full ./memleak
==29661== Memcheck, a memory error detector.
==29661== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29661== Using LibVEX rev 1732, a library for dynamic binary translation.
==29661== Copyright (C) , and GNU GPL'd, by OpenWorks LLP.
==29661== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==29661== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29661== For more details, rerun with: -v
==29661== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==29661== malloc/free: in use at exit: 10 bytes in 1 blocks.
==29661== malloc/free: 1 allocs, 0 frees, 10 bytes allocated.
==29661== For counts of detected errors, rerun with: -v
==29661== searching for pointers to 1 not-freed blocks.
==29661== checked 56,164 bytes.
==29661== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1
==29661==&&&&at 0x401A846: malloc (vg_replace_malloc.c:149)
==29661==&&&&by 0x804835D: main (memleak.c:6)
==29661== LEAK SUMMARY:
==29661==&&&&definitely lost: 10 bytes in 1 blocks.
==29661==&&&&&&possibly lost: 0 bytes in 0 blocks.
==29661==&&&&still reachable: 0 bytes in 0 blocks.
==29661==&&&&&&&&&suppressed: 0 bytes in 0 blocks.
[konten@tencent test_valgrind]$
和上次的执行结果基本相同，只是多了上面蓝色的部分，指明了代码中出现泄漏的具体位置。
以上就是用valgrind检查内存泄漏的方法，用到的例子比较简单，复杂的代码最后结果也都一样。
2、其他内存问题
&&&&&&&我们下面的例子中包括常见的几类内存问题：堆中的内存越界、踩内存、栈中的内存越界、非法指针使用、重复free。
#include &stdlib.h&
#include &stdio.h&
int main(void)
&&&&char *ptr = malloc(10);
&&&&ptr[12] = 'a'; //&内存越界
&&&&memcpy(ptr &#43;1, ptr, 5); //&踩内存
&&&&char a[10];
&&&&a[12] = 'i';&//&数组越界
&&&&&free(ptr);&//&重复释放
&&&&&&&free(ptr);
&&&&char *p1;
&&&&*p1 = '1';&//&非法指针
&&&&return 0;
编译：&gcc -o invalidptr invalidptr.c -g
执行：valgrind --leak-check=full ./invalidptr
结果如下：
[konten@tencent test_valgrind]$ valgrind --leak-check=full ./invalidptr
==29776== Memcheck, a memory error detector.
==29776== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29776== Using LibVEX rev 1732, a library for dynamic binary translation.
==29776== Copyright (C) , and GNU GPL'd, by OpenWorks LLP.
==29776== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==29776== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29776== For more details, rerun with: -v
==29776== Invalid write of size 1&//堆内存越界被查出来
==29776==&&&&at 0x80483D2: main (invalidptr.c:7)
==29776==&Address 0x4159034 is 2 bytes after a block of size 10 alloc'd
==29776==&&&&at 0x401A846: malloc (vg_replace_malloc.c:149)
==29776==&&&&by 0x80483C5: main (invalidptr.c:6)
==29776== Source and destination overlap in memcpy(0xx)&//踩内存
==29776==&&&&at 0x401C96D: memcpy (mc_replace_strmem.c:116)
==29776==&&&&by 0x80483E6: main (invalidptr.c:9)
==29776== Invalid free() / delete / delete[]&//重复释放
==29776==&&&&at 0x401B3FB: free (vg_replace_malloc.c:233)
==29776==&&&&by 0x8048406: main (invalidptr.c:16)
==29776==&Address 0x4159028 is 0 bytes inside a block of size 10 free'd
==29776==&&&&at 0x401B3FB: free (vg_replace_malloc.c:233)
==29776==&&&&by 0x80483F8: main (invalidptr.c:15)
==29776== Use of uninitialised value of size 4
==29776==&&&&at 0x804840D: main (invalidptr.c:19)
==29776==&//非法指针，导致coredump
==29776== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29776==&Bad permissions for mapped region at address 0x80482AD
==29776==&&&&at 0x804840D: main (invalidptr.c:19)
==29776== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 15 from 1)
==29776== malloc/free: in use at exit: 0 bytes in 0 blocks.
==29776== malloc/free: 1 allocs, 2 frees, 10 bytes allocated.
==29776== For counts of detected errors, rerun with: -v
==29776== All heap blocks were freed -- no leaks are possible.
Segmentation fault
[konten@tencent test_valgrind]$
从上面的结果看出，除了栈内存越界外，其他常见的内存问题都可以用valgrind简单的查出来。
3、显示代码覆盖
&&&&&&&用callgrind工具能方便的显示程序执行的代码覆盖情况。
&&&&&&&看如下例子：
4、显示线程竞态条件&&该版本暂不支持&
&&&&&&&用helgrind工具可以在多线程代码中找到可能产生竞态条件的地方。
四&memcheck&工具的常用选型
1、leak-check
&&&&--leak-check=&no|summary|yes|full& [default: summary]
&&&&用于控制内存泄漏检测力度。
&&&&no，不检测内存泄漏；
&&&&summary，仅报告总共泄漏的数量，不报告具体泄漏位置；
&&&&yes/full，报告泄漏总数、泄漏的具体位置。
2、show-reachable
&&&&--show-reachable=&yes|no& [default: no]
&&&&用于控制是否检测控制范围之外的泄漏，比如全局指针、static指针等。
#include &stdlib.h&
#include &stdio.h&
//char *gptr = NULL;
int main(void)
&&&&gptr = (char *)malloc(10);
&&&&return 0;
对应以上代码，若--show-reachable为no，则valgrind不报告内存泄漏，否则会报告。
3、undef-value-errors
--undef-value-errors=&yes|no& [default: yes]
用于控制是否检测代码中使用未初始化变量的情况。
对应以下代码：
&&&&printf(&a = %d \n&, a);
若&--undef-value-errors＝no，则valgrind不报告错误，否则报告“Use of uninitialised value ...”的错误。
4、其他选项
&&&&--log-file=filename&将结果输出到文件。
&&&&--log-socket=192.168.0.1:12345&输出到网络。
&&&&--trace-children=&yes|no& [default: no]
&&&&--track-fds=&yes|no& [default: no]
&&&&--log-fd=&number& [default: 2, stderr]
&&&&--xml=&yes|no& [default: no]
&&&&--num-callers=&number& [default: 12]
&&&&--show-below-main=&yes|no& [default: no]
五&Valgrind的编译安装
&&&&&&&1、下载源代码，下载地址http://valgrind.org/downloads/current.html#current&，截止目前为止，最新版本是3.2.3
&&&&&&&2、编译，在源代码目录下执行：
&&&&&&&&&&&&&&./configure --prefix=[你自己的安装目录]
&&&&&&&&&&&&&&make install
&&&&&&&便好了。
&&&&&&&3、配置缺省选项
&&&&&&&&&&&&&&valgrind提供3种方式用于设置缺省选项：
&&&&&&&&&&&&&&&&&&&&&a、~/.valgrindrc文件；
&&&&&&&&&&&b、环境变量$VALGRIND_OPTS；
&&&&&&&&&&&c、当前目录下的.valgrindrc文件；
&&&&&&&优先顺序为&a、b、c
&&&&&&&.valgrindrc的&#26684;式为：
&&&&&&&&&&&--ToolName:OptionName=OptionVal
&&&&&&&如：
&&&&&&&&&&&&&&&--memcheck:leak-check=yes
&&&&&&&&&&&&&&
--memcheck:show-reachable=yes
转自：/wangkangluo1/archive//2111248.html
五种泄漏类型
&definitely lost&：确认丢失。程序中存在内存泄露，应尽快修复。当程序结束时如果一块动态分配的内存没有被释放且通过程序内的指针变量均无法访问这块内存则会报这个错误。
&indirectly lost&：间接丢失。当使用了含有指针成员的类或结构时可能会报这个错误。这类错误无需直接修复，他们总是与&definitely lost&一起出现，只要修复&definitely lost&即可。例子可参考我的例程。
&possibly lost&：可能丢失。大多数情况下应视为与&definitely lost&一样需要尽快修复，除非你的程序让一个指针指向一块动态分配的内存（但不是这块内存起始地址），然后通过运算得到这块内存起始地址，再释放它。例子可参考我的例程。当程序结束时如果一块动态分配的内存没有被释放且通过程序内的指针变量均无法访问这块内存的起始地址，但可以访问其中的某一部分数据，则会报这个错误。
&still reachable&：可以访问，未丢失但也未释放。如果程序是正常结束的，那么它可能不会造成程序崩溃，但长时间运行有可能耗尽系统资源，因此笔者建议修复它。如果程序是崩溃（如访问非法的地址而崩溃）而非正常结束的，则应当暂时忽略它，先修复导致程序崩溃的错误，然后重新检测。
&suppressed&：已被解决。出现了内存泄露但系统自动处理了。可以无视这类错误。这类错误我没能用例程触发，看官方的解释也不太清楚是操作系统处理的还是valgrind，也没有遇到过。所以无视他吧~
测试程序：
源码(C&#43;&#43;)：
#include &stdio.h&
#include &stdlib.h&
char *m_pcD
m_pcData=(char*)malloc(10);
if(m_pcData) delete m_pcD
char *Fun1()//definitely lost
pcTemp=(char*)malloc(10);
return pcT
char *Fun2()//still reachable
static char *s_pcTemp=NULL;
if(s_pcTemp==NULL) s_pcTemp=(char*)malloc(10);
return NULL;
char *Fun3()//possibly lost
static char *s_pcT
pcData=(char*)malloc(10);
s_pcTemp=pcData&#43;1;
return NULL;
int Fun4()//definitely and indirectly lost
pobjTest=new c1();
char *Fun5()//possibly lost but no need of repair,repair the breakdown then no memory leak
int i,*piTemp=NULL;
pcData=(char*)malloc(10);
pcData&#43;=10;
for(i=0;i&10;i&#43;&#43;)
*pcData=0;
if(i==5) *piTemp=1;//create a breakdown
free(pcData);
return NULL;
int main()
printf(&This program will create various memory leak,use valgrind to observe it.\n&);
printf(&Following functions are bad codes,don\'t imitate.\n&);
printf(&Fun1\n&);
printf(&Fun2\n&);
printf(&Fun3\n&);
printf(&Fun4\n&);
printf(&Fun5\n&);
printf(&end\n&);
使用valgrind运行结果：
[root@localhost valtest]# valgrind --tool=memcheck --leak-check=yes ./valtest&
==29240== Memcheck, a memory error detector
==29240== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==29240== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==29240== Command: ./valtest
==29240==&
This program will create various memory leak,use valgrind to observe it.
Following functions are bad codes,don't imitate.
==29240== Invalid write of size 4
==29240== & &at 0x4007BE: Fun5() (main.cpp:73)
==29240== & &by 0x40086E: main (main.cpp:93)
==29240== &Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29240==&
==29240==&
==29240== Process terminating with default action of signal 11 (SIGSEGV)
==29240== &Access not within mapped region at address 0x0
==29240== & &at 0x4007BE: Fun5() (main.cpp:73)
==29240== & &by 0x40086E: main (main.cpp:93)
==29240== &If you believe this happened as a result of a stack
==29240== &overflow in your program's main thread (unlikely but
==29240== &possible), you can try to increase the size of the
==29240== &main thread stack using the --main-stacksize= flag.
==29240== &The main thread stack size used in this run was .
==29240==&
==29240== HEAP SUMMARY:
==29240== & & in use at exit: 58 bytes in 6 blocks
==29240== & total heap usage: 6 allocs, 0 frees, 58 bytes allocated
==29240==&
==29240== 10 bytes in 1 blocks are possibly lost in loss record 2 of 6
==29240== & &at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240== & &by 0x4006D9: Fun3() (main.cpp:46)
==29240== & &by 0x400850: main (main.cpp:89)
==29240==&
==29240== 10 bytes in 1 blocks are possibly lost in loss record 3 of 6
==29240== & &at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240== & &by 0x400795: Fun5() (main.cpp:66)
==29240== & &by 0x40086E: main (main.cpp:93)
==29240==&
==29240== 10 bytes in 1 blocks are definitely lost in loss record 5 of 6
==29240== & &at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240== & &by 0x40072D: Fun1() (main.cpp:28)
==29240== & &by 0x400832: main (main.cpp:85)
==29240==&
==29240== 18 (8 direct, 10 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6
==29240== & &at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
==29240== & &by 0x4007F0: Fun4() (main.cpp:56)
==29240== & &by 0x40085F: main (main.cpp:91)
==29240==&
==29240== LEAK SUMMARY:
==29240== & &definitely lost: 18 bytes in 2 blocks
==29240== & &indirectly lost: 10 bytes in 1 blocks
==29240== & & &possibly lost: 20 bytes in 2 blocks
==29240== & &still reachable: 10 bytes in 1 blocks
==29240== & & & & suppressed: 0 bytes in 0 blocks
==29240== Reachable blocks (those to which a pointer was found) are not shown.
==29240== To see them, rerun with: --leak-check=full --show-reachable=yes
==29240==&
==29240== For counts of detected and suppressed errors, rerun with: -v
==29240== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from 4)
就这样，结束
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：28778次
排名：千里之外
原创：34篇
转载：78篇
(1)(2)(2)(2)(3)(2)(1)(2)(5)(5)(10)(1)(4)(2)(1)(4)(10)(1)(11)(1)(1)(1)(2)(38)}