GCC memory leak detection equivalent to Microsoft crtdbg.h?
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:
#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.
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.
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?
你应该看看“跨平台内存泄漏检测器”，看起来非常类似于crtdbg.h技术。
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.
Second, you can always use a library that uses the LD_PRELOAD trick. 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 dmalloc and efence to be quite extensive in the debugging facilities that they offer.
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.
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.
You may also find the MALLOC_CHECK_ environment variable useful.
From malloc(3) man page:
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.
链接地址: http://www.djcxy.com/p/19926.html上一篇: 内存泄漏未被CRT内存泄漏检测检测到