blocks|key|1557626|text|我自己从来没有用过它，但是我的C朋友告诉我Purify。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1557627|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/IBM_Rational_Purify^0|L|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Never used it myself, but my C friends tell me <a href="http://en.wikipedia.org/wiki/IBM_Rational_Purify" rel="nofollow noreferrer">Purify</a>.

blocks|key|1557711|text|有各种替代的"malloc“库，允许你在最后调用一个函数，它会告诉你所有未释放的内存，在许多情况下，是谁在第一个地方错误地分配(或新的)它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1557712|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are various replacement "malloc" libraries out there that will allow you to call a function at the end and it will tell you about all the unfreed memory, and in many cases, who malloced (or new'ed) it in the first place.

blocks|key|1557795|text|如果你的C/C%2B%2B代码可以移植到*nix，那么没有什么比Valgrind更好的了。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1557796|entityMap|0|LINK|mutability|MUTABLE|url|http://valgrind.org/info/about.html^0|S|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If your C/C++ code is portable to *nix, few things are better than <a href="http://valgrind.org/info/about.html" rel="noreferrer">Valgrind</a>.

blocks|key|1557850|text|在摩托罗拉手机操作系统上，我们劫持了内存分配库来观察所有的内存分配。它有助于发现内存分配的许多问题。由于预防比治疗更好，我建议使用静态分析工具，如Klockwork或PC-Lint|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1557851|entityMap|0|LINK|mutability|MUTABLE|url|http://www.klocwork.com/products/insight.asp|1|http://www.gimpel.com/^0|21|9|0|2B|7|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Working on Motorola cell phones operating system, we hijacked memory allocation library to observe all memory allocations. It helped to find a lot of problems with memory allocations. 
Since prevention is better then curing, I would recommend to use static analysis tool like <a href="http://www.klocwork.com/products/insight.asp" rel="nofollow noreferrer">Klockwork</a> or <a href="http://www.gimpel.com" rel="nofollow noreferrer">PC-Lint</a>

blocks|key|1773087|text|您是否通过插入自己的syscall函数来计算分配和释放数，这些函数记录调用，然后将调用传递给真正的函数？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773088|这是您可以跟踪源自您未编写的代码的调用的唯一方法。|1773089|请看一下ld.so的手册页。或ld.so.1在某些系统上。|1773090|此外，在www.itworld.com上也可以找到一些有趣的文章来解释这项技术。|1773091|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Are you counting the allocs and frees by interpolating your own syscall functions which record the calls and then pass the call to the real function?

This is the only way you can keep track of calls originating from code that you haven't written.

Have a look at the man page for ld.so. Or ld.so.1 on some systems.

Also do Google LD_PRELOAD and you'll find some interesting articles explaining the technique over on www.itworld.com.

blocks|key|1557994|text|调试模式下的Microsoft+VC%2B%2B会显示内存泄漏，尽管它不会显示泄漏的位置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1557995|如果你正在使用C%2B%2B，你总是可以避免显式地使用new+:你的工具库中有vector，string，auto_ptr+(在C%2B%2B11之前；在C%2B%2B11中被unique_ptr取代)，unique_ptr+(+C%2B%2B11)和shared_ptr+(C%2B%2B11)。|offset|length|style|CODE|1557996|当new不可避免时，尝试将其隐藏在构造函数中(并在析构函数中隐藏delete+)；同样的方法也适用于第三方API。|1557997|entityMap^0|0|Z|6|16|6|1D|8|24|A|2I|A|32|A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]|$D|T|E|U|F|G]|$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|K|$]]

Microsoft VC++ in debug mode shows memory leaks, although it doesn't show where your leaks are.

If you are using C++ you can always avoid using new explicitly: you have <code>vector</code>, <code>string</code>, <code>auto_ptr</code> (pre C++11; replaced by <code>unique_ptr</code> in C++11), <code>unique_ptr</code> (C++11) and <code>shared_ptr</code> (C++11) in your arsenal.

When new is unavoidable, try to hide it in a constructor (and hide delete in a destructor); the same works for 3rd party APIs.

blocks|key|1773236|text|如果您使用的是Visual+Studio，那么Bounds+Checker可能值得一看。它不是免费的，但它在查找我的代码中的漏洞方面有令人难以置信的帮助。它不仅会造成内存泄漏，还会造成GDI资源泄漏、WinAPI使用错误和其他问题。它甚至会告诉你泄漏的内存是在哪里被初始化的，这使得追踪泄漏更加容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1773237|entityMap|0|LINK|mutability|MUTABLE|url|http://www.compuware.com/products/devpartner/visualc.htm^0|N|E|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If you're using Visual Studio it might be worth looking at <a href="http://www.compuware.com/products/devpartner/visualc.htm" rel="nofollow noreferrer">Bounds Checker</a>. It's not free, but it's been incredibly helpful in finding leaks in my code. It doesn't just do memory leaks either, but also GDI resource leaks, WinAPI usage errors, and other stuff. It'll even show you where the leaked memory was initialized, making it much easier to track down the leak.

blocks|key|1773315|text|如果你正在使用MS+VC%2B%2B，我可以强烈推荐这个来自代码项目的免费工具:+Jochen+Kalmbach的leakfinder。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1773316|您只需将类添加到项目中，然后调用|1773317|InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()|code-block|syntax|javascript|1773318|在您想要检查的代码之前和之后检查是否有泄漏。|1773319|构建并运行代码后，Jochen提供了一个简洁的图形用户界面工具，您可以在其中加载生成的.xmlleaks文件，并在每次泄漏产生的调用堆栈中导航，以查找有问题的代码行。|1773320|Rational的PurifyPlus+(现在归IBM所有)以类似的方式说明了泄漏，但我发现leakfinder工具实际上更容易使用，而且它的好处是不需要花费数千美元！|1773321|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/KB/applications/leakfinder.aspx^0|1H|A|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

If you're using MS VC++, I can highly recommend this free tool from the codeproject:
<a href="http://www.codeproject.com/KB/applications/leakfinder.aspx" rel="nofollow noreferrer">leakfinder</a> by Jochen Kalmbach.

You simply add the class to your project, and call

<pre><code>InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()
</code></pre>

before and after the code you want to check for leaks.

Once you've build and run the code, Jochen provides a neat GUI tool where you can load the resulting .xmlleaks file, and navigate through the call stack where each leak was generated to hunt down the offending line of code. 

Rational's (now owned by IBM) PurifyPlus illustrates leaks in a similar fashion, but I find the leakfinder tool actually easier to use, with the bonus of it not costing several thousand dollars!

blocks|key|1773393|text|我使用DevStudio已经有很多年了，很多程序员都不知道调试运行时库中提供的内存分析工具，这总是让我感到惊讶。下面是一些可以开始使用的链接：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773394|Tracking+Heap+Allocation+Requests+--特别是关于唯一分配请求号的部分|offset|length|1773395|_CrtSetDbgFlag|style|CODE|1773396|_CrtSetBreakAlloc|1773397|当然，如果您不使用DevStudio，那么这不会有什么特别的帮助。|1773398|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/aa297305(v=vs.60).aspx|1|http://msdn.microsoft.com/en-us/library/5at7yxcs.aspx|2|http://msdn.microsoft.com/en-us/library/4wth1ha5.aspx^0|0|0|X|0|0|0|E|0|E|1|0|0|H|0|H|2|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|F|3|G|5|6|7|14|8|@$D|15|E|16|H|I]]|9|@$D|17|E|18|1|19]]|A|$]]|$1|J|3|K|5|6|7|1A|8|@$D|1B|E|1C|H|I]]|9|@$D|1D|E|1E|1|1F]]|A|$]]|$1|L|3|M|5|6|7|1G|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]|X|$5|Q|R|S|A|$T|Y]]]]

I've been using DevStudio for far too many years now and it always amazes me just how many programmers don't know about the memory analysis tools that are available in the debug run time libraries. Here's a few links to get started with:

<a href="https://msdn.microsoft.com/en-us/library/aa297305(v=vs.60).aspx" rel="nofollow noreferrer">Tracking Heap Allocation Requests</a> - specifically the section on Unique Allocation Request Numbers

<a href="http://msdn.microsoft.com/en-us/library/5at7yxcs.aspx" rel="nofollow noreferrer"><code>_CrtSetDbgFlag</code></a>

<a href="http://msdn.microsoft.com/en-us/library/4wth1ha5.aspx" rel="nofollow noreferrer"><code>_CrtSetBreakAlloc</code></a>

Of course, if you're not using DevStudio then this won't be particularly helpful.

blocks|key|1558244|text|至少对于MS+VC%2B%2B来说，C运行时库有几个我在过去发现有帮助的函数。有关_Crt*函数，请查看MSDN帮助。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1558245|entityMap^0|11|5|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

At least for MS VC++, the C Runtime library has several functions that I've found helpful in the past. Check the MSDN help for the <code>_Crt*</code> functions.

blocks|key|1558291|text|在C%2B%2B中:使用RAII。像std::unique_ptr，std::shared_ptr，std::weak_ptr这样的智能指针是你的朋友。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1558292|entityMap^0|E|F|U|F|1A|D|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

In C++: use RAII. Smart pointers like <code>std::unique_ptr</code>, <code>std::shared_ptr</code>, <code>std::weak_ptr</code> are your friends.

blocks|key|1773583|text|Valgrind是Linux的一个很好的选择。在MacOS+X下，您可以启用MallocDebug库，该库有几个用于调试内存分配问题的选项(请参阅malloc手册页，“环境”部分有相关的详细信息)。OS还包括一个名为MallocDebug的工具(通常安装在/Developer/Applications/Performance+Tools/中)，它可以帮助您监视使用情况和泄漏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773584|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Valgrind is a nice option for Linux. Under MacOS X, you can enable the MallocDebug library which has several options for debugging memory allocation problems (see the malloc manpage, the "ENVIRONMENT" section has the relevant details). The OS X SDK also includes a tool called MallocDebug (usually installed in /Developer/Applications/Performance Tools/) that can help you to monitor usage and leaks.

blocks|key|1773645|text|我认为这个问题没有简单的答案。您如何真正实现此解决方案取决于您的需求。您是否需要跨平台解决方案？您使用的是new/delete还是malloc/free+(或两者都使用)？您真的只是在寻找“泄漏”，还是想要更好的保护，比如检测缓冲区溢出(或欠载)？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773646|如果您使用的是Windows端，则MS调试运行时库具有一些基本的调试检测功能，并且正如另一个人已经指出的那样，源代码中可以包含几个包装器来帮助进行泄漏检测。找到一个可以同时使用new/delete和malloc/free的包显然会给你带来更大的灵活性。|1773647|我对unix方面的了解还不够多，无法提供帮助，尽管其他人也有。|1773648|但除了泄漏检测之外，还有通过缓冲区溢出(或欠载运行)检测内存损坏的概念。我认为这种类型的调试功能比普通的泄漏检测更难。如果您使用的是C%2B%2B对象，这种类型的系统也会更加复杂，因为多态类可以以不同的方式删除，从而导致在确定要删除的真正基指针时出现麻烦。据我所知，没有一个好的“免费”系统能很好地保护超支。我们已经写了一个系统(跨平台)，发现它很有挑战性。|1773649|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think that there is no easy answer to this question. How you might really approach this solution depends on your requirements. Do you need a cross platform solution? Are you using new/delete or malloc/free (or both)? Are you really looking for just "leaks" or do you want better protection, such as detecting buffer overruns (or underruns)?

If you are working on the windows side, the MS debug runtime libraries have some basic debug detection functionality, and as another has already pointed out, there are several wrappers that can be included in your source to help with leak detection. Finding a package that can work with both new/delete and malloc/free obviously gives you more flexibility.

I don't know enough about the unix side to provide help, although again, others have.

But beyond just leak detection, there is the notion of detecting memory corruption via buffer overruns (or underruns). This type of debug functionality is I think more difficult than plain leak detection. This type of system is also further complicated if you are working with C++ objects because polymorhpic classes can be deleted in varying ways causing trickiness in determining the true base pointer that is being deleted. I know of no good "free" system that does decent protection for overruns. we have written a system (cross platform) and found it to be pretty challenging.

blocks|key|1773694|text|检测：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773695|调试CRT|1773696|避免：|1773697|智能指针，boehm+GC|1773698|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Detect:

Debug CRT

Avoid:

Smart pointers, boehm GC

blocks|key|1558535|text|如果您使用的是Visual+Studio，Microsoft提供了一些用于检测和调试内存泄漏的有用函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558536|我将从这篇文章开始：https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx|offset|length|1558537|以下是这些文章的快速摘要。首先，包含以下标头：|1558538|#define+_CRTDBG_MAP_ALLOC
#include+<stdlib.h>
#include+<crtdbg.h>|code-block|syntax|javascript|1558539|然后，您需要在程序退出时调用以下代码：|1558540|_CrtDumpMemoryLeaks();|1558541|或者，如果您的程序不是每次都在同一位置退出，您可以在程序开始时调用以下代码：|1558542|_CrtSetDbgFlag+(+_CRTDBG_ALLOC_MEM_DF+%7C+_CRTDBG_LEAK_CHECK_DF+);|1558543|现在，当程序退出时，所有不是空闲的分配都将在输出窗口中打印出来，以及它们被分配到的文件和分配的发生。|1558544|此策略适用于大多数程序。然而，在某些情况下，这会变得困难或不可能。使用在启动时执行一些初始化的第三方库可能会导致其他对象出现在内存转储中，并使追踪泄漏变得困难。此外，如果您的任何类具有与任何内存分配例程(如malloc+)同名的成员，则CRT调试宏将导致问题。|1558545|在上面引用的MSDN链接中解释的其他技术也可以使用。|1558546|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx^0|0|A|1S|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1E|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1G|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1I|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1L|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

If you are using Visual Studio, Microsoft provides some useful functions for detecting and debugging memory leaks.

I would start with this article:
<a href="https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx" rel="nofollow noreferrer">https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx</a>

Here is the quick summary of those articles. First, include these headers:

<pre><code>#define _CRTDBG_MAP_ALLOC
#include &lt;stdlib.h&gt;
#include &lt;crtdbg.h&gt;
</code></pre>

Then you need to call this when your program exits:

<pre><code>_CrtDumpMemoryLeaks();
</code></pre>

Alternatively, if your program does not exit in the same place every time, you can call this at the start of your program:

<pre><code>_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
</code></pre>

Now when the program exits all the allocations that were not free'd will be printed in the Output Window along with the file they were allocated in and the allocation occurrence.

This strategy works for most programs. However, it becomes difficult or impossible in certain cases. Using third party libraries that do some initialization on startup may cause other objects to appear in the memory dump and can make tracking down your leaks difficult. Also, if any of your classes have members with the same name as any of the memory allocation routines( such as malloc ), the CRT debug macros will cause problems.

There are other techniques explained in the MSDN link referenced above that could be used as well.

blocks|key|1773824|text|Paul+Nettle's+mmgr是我长期以来最喜欢的工具。你将mmgr.h包含在你的源文件中，定义TEST_MEMORY，它会提供一个充满内存问题的文本文件，这些问题是在你的应用程序运行期间发生的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1773825|entityMap|0|LINK|mutability|MUTABLE|url|http://www.paulnettle.com/^0|0|I|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="http://www.paulnettle.com/" rel="nofollow noreferrer">Paul Nettle's mmgr</a> is a long time favourite tool of mine. You include mmgr.h in your source files, define TEST_MEMORY, and it delivers a textfile full of memory problems that occurred during a run of your app.

blocks|key|1558690|text|对泄漏的最好防御是最大限度地减少malloc使用的程序结构。这不仅从编程的角度来看是好的，而且还提高了性能和可维护性。我不是在谈论使用其他东西来代替malloc，而是在重用对象和对传递的所有对象保持非常显式的标签方面，而不是像使用Java这样的垃圾收集器的语言中经常习惯的随意分配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558691|例如，我工作的一个程序有一堆表示图像数据的frame对象。每个frame对象都有子数据，frame的析构函数释放了这些数据。程序保存所有已分配帧的列表，当需要新的帧时，检查未使用的帧对象的列表，看看是否可以重用现有的帧对象，而不是分配新的帧对象。在关机时，它只是遍历列表，释放所有内容。|1558692|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The best defense against leaks is a program structure which minimizes the use of malloc. This is not only good from a programming perspective, but also improves performance and maintainability. I'm not talking about using other things in place of malloc, but in terms of re-using objects and keeping very explicit tabs on all objects being passed around rather than allocating willy-nilly like one often gets used to in languages with garbage collectors like Java.

For example, a program I work on has a bunch of frame objects representing image data. Each frame object has sub-data, which the frame's destructor frees. The program keeps a list of all frames that are allocated, and when it needs a new one, checks a list of unused frame objects to see if it can re-use an existing one rather than allocate a new one. On shutdown, it just iterates through the list, freeing everything.

blocks|key|1558761|text|我推荐使用software+verify中的Memory+Validator。事实证明，这个工具在帮助我追踪内存泄漏和改进我正在处理的应用程序的内存管理方面提供了无价的帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1558762|一个非常完整和快速的工具。|1558763|entityMap|0|LINK|mutability|MUTABLE|url|http://www.softwareverify.com/cpp/memory/index.html^0|M|G|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I would recommend using <a href="http://www.softwareverify.com/cpp/memory/index.html" rel="nofollow noreferrer">Memory Validator</a> from software verify.
This tool proved itself to be of invaluable help to help me track down memory leaks and to improve the memory management of the applications i am working on. 

A very complete and fast tool.

blocks|key|1774014|text|我很惊讶没有人提到用于Windows操作系统的DebugDiag。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1774015|它在发布版本上有效，甚至在客户站点上也有效。|1774016|(您只需保留您的发行版PDB，并将DebugDiag配置为使用微软公共符号服务器)|1774017|entityMap|0|LINK|mutability|MUTABLE|url|http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en^0|N|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I’m amazed no one mentioned <a href="http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&amp;displaylang=en" rel="noreferrer">DebugDiag</a> for Windows OS. 
It works on release builds, and even at the customer site. 
(You just need to keep your release version PDBs, and configure DebugDiag to use Microsoft public symbol server)

blocks|key|1774112|text|一个很好的malloc，calloc和reallloc的替代品是rmdebug，它使用起来非常简单。它比valgrind快得多，所以你可以广泛地测试你的代码。当然它也有一些缺点，一旦你发现了一个漏洞，你可能仍然需要使用valgrind来找出漏洞出现的地方，并且你只能测试你直接做的mallocs。如果库因为使用不当而泄漏，rmdebug将找不到它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774113|http://www.hexco.de/rmdebug/|offset|length|1774114|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|S|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

A nice malloc, calloc and reallloc replacement is rmdebug, it's pretty simple to use. It is much faster to then valgrind, so you can test your code extensively. Of course it has some downsides, once you found a leak you probably still need to use valgrind to find where the leak appears and you can only test mallocs that you do directly. If a lib leaks because you use it wrong, rmdebug won't find it.

<a href="http://www.hexco.de/rmdebug/" rel="nofollow noreferrer">http://www.hexco.de/rmdebug/</a>

blocks|key|1774165|text|可视化泄漏检测器是一个非常好的工具，尽管它不支持在VC9运行时(例如MSVCR90D.DLL)上的调用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774166|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Visual Leak Detector is a very good tool, altough it does not supports the calls on VC9 runtimes (MSVCR90D.DLL for example).

blocks|key|1559052|text|在这个列表的顶部(当我读到它的时候)是valgrind。如果您能够在测试系统上重现泄漏，Valgrind就是最好的选择。我使用它取得了巨大的成功。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1559053|如果您刚刚注意到生产系统正在泄漏，而您不知道如何在测试中重现它，该怎么办呢？在生产系统的状态中捕获了问题所在的一些证据，这可能足以提供问题所在的洞察，以便您可以重现问题。|1559054|这就是蒙特卡洛抽样的用武之地。阅读Raymond+Chen的博客文章“可怜的人识别内存泄漏的方法”，然后看看我的实现(假设Linux，只在x86和x86-64上测试)|1559055|http://github.com/tialaramex/leakdice/tree/master|offset|length|1559056|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1D|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@$H|U|I|V|1|W]]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|G]]]]

At the top of this list (when I read it) was valgrind. Valgrind is excellent if you are able to reproduce the leak on a test system. I've used it with great success.

What if you've just noticed that the production system is leaking right now and you have no idea how to reproduce it in test? Some evidence of what's wrong is captured in the state of that production system, and it might be enough to provide an insight on where the problem is so you can reproduce it.

That's where Monte Carlo sampling comes into the picture. Read Raymond Chen's blog article,
“The poor man's way of identifying memory leaks” and then check out my implementation (assumes Linux, tested only on x86 and x86-64)

<a href="http://github.com/tialaramex/leakdice/tree/master" rel="nofollow noreferrer">http://github.com/tialaramex/leakdice/tree/master</a>

blocks|key|1774316|text|大多数内存分析器都会减慢我的大型复杂Windows应用程序的运行速度，直到结果变得无用。有一个工具可以很好地查找应用程序中的漏洞:+UMDH+http://msdn.microsoft.com/en-us/library/ff560206%2528VS.85%2529.aspx|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1774317|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ff560206%2528VS.85%2529.aspx^0|1Z|1S|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Most memory profilers slow my large complex Windows application to the point where the results are useless. There is one tool that works well for finding leaks in my application: UMDH - <a href="http://msdn.microsoft.com/en-us/library/ff560206%28VS.85%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ff560206%28VS.85%29.aspx</a>

In unmanaged C/C++ code, what are the best practices to detect memory leaks? And coding guidelines to avoid? (As if it's that simple ;)

We have used a bit of a silly way in the past: having a counter increment for every memory allocation call and decrement while freeing. At the end of the program, the counter value should be zero.

I know this is not a great way and there are a few catches. (For instance, if you are freeing memory which was allocated by a platform API call, your allocation count will not exactly match your freeing count. Of course, then we incremented the counter when calling API calls that allocated memory.)

I am expecting your experiences, suggestions and maybe some references to tools which simplify this.

How do you detect/avoid Memory leaks in your (Unmanaged) code?

Visual Studio

内存管理

服务器

Windows

Linux

MacOS

Java

在非托管C/C++代码中，检测内存泄漏的最佳实践是什么？以及要避免的编码指南？(好像事情就是这么简单;)我们在过去使用了一种有点愚蠢的方式:每次内存分配调用都有一个计数器递增，并在释放时递减。在程序结束时，计数器值应为零。我知道这不是一个很好的方法，但也有一些问题。(例如，如果您正在释放由平台API调用分配的内存，则您...

问如何检测/避免(非托管)代码中的内存泄漏？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何检测/避免(非托管)代码中的内存泄漏？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何检测/避免(非托管)代码中的内存泄漏？
EN