GCC memory leak detection equivalent to Microsoft 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 should have a look at "Cross-Platform Memory Leak Detector", looks very similar to the crtdbg.h technique.

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.