xcode GCC 内存泄漏检测相当于 Microsoft crtdbg.h？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1761125/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
GCC memory leak detection equivalent to Microsoft crtdbg.h?
提问by Gene Goykhman
After many years of working on a general-purpose C++ library using the Microsoft MSVC compiler in Visual Studio, we are now porting it to Linux/Mac OS X (pray for us). I have become accustomed and quite fond of the simple memory leak detection mechanism in MSVC:
在使用 Visual Studio 中的 Microsoft MSVC 编译器开发通用 C++ 库多年之后，我们现在将其移植到 Linux/Mac OS X（为我们祈祷）。我已经习惯并非常喜欢 MSVC 中简单的内存泄漏检测机制：
#ifdef DEBUG
#define _CRTDBG_MAP_ALLOC
#define NEW new( _NORMAL_BLOCK, __FILE__, __LINE__)
#include <stdlib.h>
#include <crtdbg.h>
#else
#define NEW new
#endif
Every memory allocation is done using this NEW macro. Whenever a process using our library terminates, any memory leaks (blocks that have not been de-allocated) are reported on the console along with the file and line # where the memory was originally allocated.
每个内存分配都是使用这个 NEW 宏完成的。每当使用我们库的进程终止时，任何内存泄漏（尚未解除分配的块）都会在控制台上与文件和最初分配内存的行 # 一起报告。
The part about this that I like is that I don't have to actively "run with performance tool" or otherwise indicate that I am looking for leaks. Leaks are reported to me in the regular course of development, every time a process terminates.
我喜欢的部分是我不必主动“使用性能工具运行”或以其他方式表明我正在寻找泄漏。在常规开发过程中，每次进程终止时都会向我报告泄漏。
Now that we are moving to the GCC world, I find that the memory leak detection tools, many of which are quite sophisticated, require that I explicitly indicate that I'm in leak hunting mode. My IDE is Xcode and I've looked into some of the allocation/leak detection tools (like Instruments and MallocDebug) but I admit I haven't spent the time to get my head around them fully yet. I keep getting put off by the fact that I actually have to specify that I'm looking for a leak ahead of time, instead of being alerted to it automatically.
现在我们正在转向 GCC 世界，我发现内存泄漏检测工具（其中许多非常复杂）要求我明确指出我处于泄漏搜寻模式。我的 IDE 是 Xcode，我已经研究了一些分配/泄漏检测工具（如 Instruments 和 MallocDebug），但我承认我还没有花时间完全了解它们。我一直因为我实际上必须提前指定我正在寻找泄漏而不是自动提醒它这一事实而推迟。
I am using Xcode 3.2 and I hear that there's now nifty integration with a static analysis tool, but again I haven't looked into this. I'm looking for some idea of what my options are. Is there a comparable mechanism built into GCC and/or Xcode? Is there a simple third-party library or tool that performs the very basic functionality that I know and love? Or should I suck it up and learn the new way of doing things?
我正在使用 Xcode 3.2，我听说现在有一个与静态分析工具的漂亮集成，但我还没有研究过这个。我正在寻找一些关于我的选择的想法。GCC 和/或 Xcode 中是否有类似的机制？是否有一个简单的第三方库或工具可以执行我所了解和喜爱的非常基本的功能？或者我应该接受它并学习新的做事方式？
采纳答案by Cristian Adam
You should have a look at "Cross-Platform Memory Leak Detector", looks very similar to the crtdbg.h technique.
您应该看看“跨平台内存泄漏检测器”，它看起来与 crtdbg.h 技术非常相似。
回答by s1n
You have a number of options available to you.
您有多种选择。
First, and most popularly, you can run your application under tools like Valgrind. That should point you to a number of memory abuses, such as NULL pointer reads and writes and memory leaks. There are a number of tools available in the Valgrind suite, so be sure to check them out.
首先，也是最流行的，您可以在Valgrind 等工具下运行您的应用程序。这应该指向许多内存滥用，例如 NULL 指针读写和内存泄漏。Valgrind 套件中有许多可用的工具，因此请务必查看它们。
Second, you can always use a library that uses the LD_PRELOADtrick. Basically, the LD_PRELOAD trick allows for DLL injection, which means that tools can be created to help track your memory usage within your application without changing anything. You will find tools such as dmallocand efenceto be quite extensive in the debugging facilities that they offer.
其次，您始终可以使用使用LD_PRELOAD技巧的库。基本上，LD_PRELOAD 技巧允许 DLL 注入，这意味着可以创建工具来帮助跟踪应用程序中的内存使用情况，而无需更改任何内容。您会发现dmalloc和efence等工具在它们提供的调试工具中非常广泛。
Lastly, recent GCC releases included a tool called Mudflap. This basically uses the function instrumentation to wrap calls around the same memory functions that dmalloc, efence, and Valgrind. The program will be noticably slower, and can be tuned at runtime, though it still looks like it has much potential.
最后，最近的 GCC 版本包括一个名为Mudflap的工具。这基本上使用函数检测来包装与 dmalloc、efence 和 Valgrind 相同的内存函数的调用。该程序将明显变慢，并且可以在运行时进行调整，尽管它看起来仍然具有很大的潜力。
I have used all three and found Valgrind to be very useful. I have been very interested in using Mudflap as well, though I haven't been able to yet.
我已经使用了所有三个，发现 Valgrind 非常有用。我也对使用 Mudflap 非常感兴趣，尽管我还没有。
回答by grigy
You may also find the MALLOC_CHECK_ environment variable useful.
您可能还会发现 MALLOC_CHECK_ 环境变量很有用。
From malloc(3) man page:
从 malloc(3) 手册页：
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x) include a malloc() implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic message is printed on stderr; if set to 2, abort(3) is called immediately; if set to 3, a diagnostic message is printed on stderr and the program is aborted. Using a non-zero MALLOC_CHECK_ value can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
最新版本的 Linux libc（5.4.23 之后）和 glibc (2.x) 包括 malloc() 实现，该实现可通过环境变量进行调整。当 MALLOC_CHECK_ 被设置时，会使用一种特殊的（效率较低的）实现，该实现旨在容忍简单的错误，例如使用相同参数对 free() 的两次调用，或单个字节的溢出（逐一错误） ）。然而，并非所有此类错误都可以防止，并且可能导致内存泄漏。如果 MALLOC_CHECK_ 设置为 0，则任何检测到的堆损坏都会被静默忽略；如果设置为 1，则在 stderr 上打印诊断消息；如果设置为 2，则立即调用 abort(3)；如果设置为 3，则会在 stderr 上打印诊断消息并中止程序。使用非零的 MALLOC_CHECK_ 值可能很有用，否则崩溃可能会在很久以后发生，
回答by akosch
Maybe you could use the Boehm garbage collectoras a leak detection tool:
也许您可以使用Boehm 垃圾收集器作为泄漏检测工具：
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html
From the site:
从网站：
#include "leak_detector.h"
main() {
int *p[10];
int i;
/* GC_find_leak = 1; for new collector versions not */
/* compiled with -DFIND_LEAK. */
for (i = 0; i < 10; ++i) {
p[i] = malloc(sizeof(int)+i);
}
for (i = 1; i < 10; ++i) {
free(p[i]);
}
for (i = 0; i < 9; ++i) {
p[i] = malloc(sizeof(int)+i);
}
CHECK_LEAKS();
}
(you get notified via stderr)
（您通过 stderr 收到通知）
回答by Laurence Gonsalves
I'm not aware of anything "built-in" that does what you describe, but it doesn't seem like it would be very hard to "roll your own" version of this. You just want your debugging new to record the pointer, file and line in a map<void*, AllocationInfo>where the key is the allocated pointer and the value (AllocationInfo) would be some struct that holds the filename, line number, etc. You also need to define a custom delete operator that checks the map for the pointer being deleted. If found, that entry is removed from the map. Then at process shutdown time you emit the contents of the map.
我不知道有什么“内置”可以满足您的描述，但是“推出您自己的”版本似乎并不难。你只是想让你的调试新记录指针、文件和行，map<void*, AllocationInfo>其中键是分配的指针，值 ( AllocationInfo) 是一些保存文件名、行号等的结构。你还需要定义一个自定义删除检查映射中是否存在被删除的指针的运算符。如果找到，该条目将从地图中删除。然后在进程关闭时发出地图的内容。
I found a page where someone describes their own home-grown system that works like this.
回答by Nicholaz
I had the same problem when we started porting to the Mac. "Run with performance tool -> Leaks" was the only I found and I'm less than thrilled by it ... at least compared to CRTDEBUG. I understand there are some options (as described by others here), but eventually since we are multi platform, we're using Windows to look for the leaks.
当我们开始移植到 Mac 时，我遇到了同样的问题。“使用性能工具运行 -> 泄漏”是我唯一发现的，我对此并不感到兴奋……至少与 CRTDEBUG 相比。我知道有一些选择（如此处其他人所述），但最终由于我们是多平台的，因此我们使用 Windows 来查找泄漏。
Since you mention the static analyzer. We spent some time trying to figure out hot to get it running until we found that it only does C but not C++
既然你提到了静态分析器。我们花了一些时间试图找出让它运行的热度，直到我们发现它只能运行 C 而不能运行 C++
回答by Dirk Herrmann
Since some time both clang and gcc support some "sanitizers", including the leak sanitizer. When enabled during compilation, the code is instrumented by the compiler to perform the respective checks during run-time. On gcc the leak sanitizer is enabled using "-fsanitize=leak". See https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html.
一段时间以来，clang 和 gcc 都支持一些“消毒剂”，包括泄漏消毒剂。在编译期间启用时，编译器会检测代码以在运行时执行相应的检查。在 gcc 上，使用“-fsanitize=leak”启用泄漏消毒剂。请参阅https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html。
