I plan on using GCC more (Linux and Windows) and I was wondering if there's an equivalent of the MSVC debug heap and the STL checks available for the GCC CRT and STL.
I already know about tools such as Valgrind, but I'm looking for something built in the libraries.
The STLport version of the standard library at http://sourceforge.net/projects/stlport/ has a debug mode, which I used to use, and which is recommended by Scott Meyers in Effective STL. I haven't used it for several years now however, so I can't vouch for the current state.
There is also a thread about GCC STL debugging here, but I once again I can't vouch for the info it gives.
I've never used them, but I do know glibc has some capabilities for doing debugging of dynamically allocated memory. Here's a relevant manual entry http://www.gnu.org/s/libc/manual/html_node/Memory-Allocation.html#Memory-Allocation. "Unconstrained Allocation" has some information on various ways to hook the allocation functions and "Allocation Debugging" contains some information on glibc's abilitiy to trace allocations.
Personally, I think Valgrind is the easiest way to do it.
I'm not too familiar with the debug heap and STL checks, but when I have memory problems in GCC on linux I use an environment variable called MALLOC_CHECK_ (from malloc(3)):
Recent versions of Linux libc (later than 5.4.23) and GNU libc (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 is printed on stderr; if set to 2, abort() is called immediately. This 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.
There is also Electric Fence which can help catch buffer overruns aborting as soon as the overrun / underrun happens. See libefence(3) for more information.
Some heap debugging is available with efence/DUMA (even under MinGW)
What you're looking for can be enabled by defining _GLIBCXX_DEBUG before including any standard libraries. I'm not sure what affects this will have if you can't use it consistently. My default advice would be to be very careful. Also I've heard that the debug checks can be a big performance hit. So big that it may be unwise to always have it enabled for debug builds.