Compiler switches to ease memory debugging in C++ ?

[mathog]

When looking for memory problems in C programs hooking malloc() (and its
variants) and free() is usually enough to find memory leaks. In C++
memory can be allocated and released by programs which contain none of
these functions (explicitly). Are there any switches in gcc, or in
other C++ compilers, that cause the compiler to route memory
manipulation through these routines, or in some similar way aid in
debugging memory issues?

Thank you,

David Mathog

 

[Victor Bazarov]

When looking for memory problems in C programs hooking malloc() (and its
variants) and free() is usually enough to find memory leaks. In C++
memory can be allocated and released by programs which contain none of
these functions (explicitly). Are there any switches in gcc, or in other
C++ compilers, that cause the compiler to route memory manipulation
through these routines, or in some similar way aid in debugging memory
issues?

Compiler switches are off-topic, sorry. AFAICT, debugging memory
allocations is one of the most tedious activities AFA C++ programming is
concerned. And that's why there are third-party libraries that have
prepackaged allocators and other fancy stuff that you can use. There
are quite a few of those 3rd party libs on the market. Of course, their
use is not controlled by compiler switches. I bet that some compilers,
though, have their own allocators in the libs shipped along with the
compiler. You'd have to ask for specific ones, and in the newsgroups
that deal with those compilers, NOT HERE.

V

 

[Jorgen Grahn]

While entirely implementation specific, the answer is probably. In
most systems new and malloc end up in the same memory allocation code,
and there's usually some way of hooking things generically there.

For example, in MSVC, both new and malloc end up in _heap_alloc to do
the actual allocation.

And in gcc (which he mentioned especially) on Linux the situation is
similar. I never felt C++ was at a disadvantage in this area compared
to C.

OP: do you have some practical reason to worry? Then just write a C++
program with a leak, find the right tool, and see it find the leak.

/Jorgen

 

[mathog]

OP: do you have some practical reason to worry?

Yes, it was prompted by issues with a (large) real program:

https://bugs.launchpad.net/inkscape/+bug/986271

Not much luck yet getting the windows (mingw) version of this program to
run within a memory debugger. So far Dr.Memory won't run it on XP, and
running inkscape (windows) in wine in valgrind didn't work either. I
was hoping that if there was a compiler switch to force all memory
allocation/release into the malloc/free pathway then maybe one or the
other memory debugging programs might work. Not that I have any good
reason to think that the memory debuggers' issues running inkscape are
due to non-malloc/free memory control. But there is always mpatrol,
which won't detect reads of uninitialized memory, but is reported to do
a good job with malloc/free.

 

[Jorgen Grahn]

Yes, it was prompted by issues with a (large) real program: ....
Not much luck yet getting the windows (mingw) version of this program to
run within a memory debugger. So far Dr.Memory won't run it on XP, and
running inkscape (windows) in wine in valgrind didn't work either.

[...]

Ok, that's one environment where I can imagine tool support is weak.
(Just based on the number of people complaining about odd problems
there; I never did any Windows programming, or used "foreign"
toolchains.)

Your best bet is still to ask in some compiler- or toolchain-specific
forum.

/Jorgen

 

[Joshua Maurice]

Yes, it was prompted by issues with a (large) real program:

https://bugs.launchpad.net/inkscape/+bug/986271

Not much luck yet getting the windows (mingw) version of this program to
run within a memory debugger.  So far Dr.Memory won't run it on XP, and
running inkscape (windows) in wine in valgrind didn't work either.  I
was hoping that if there was a compiler switch to force all memory
allocation/release into the malloc/free pathway then maybe one or the
other memory debugging programs might work.  Not that I have any good
reason to think that the memory debuggers' issues running inkscape are
due to non-malloc/free memory control.  But there is always mpatrol,
which won't detect reads of uninitialized memory, but is reported to do
a good job with malloc/free.

Currently, for such debugging such things on Windows, I'm a big fan of
Memory Validator:
http://www.softwareverify.com/cpp-memory.php

I don't know if it works with mingw, but given what little I know of
mingw, I would guess that Memory Validator should work fine.

 

[Guest]

When looking for memory problems in C programs hooking malloc() (and its
variants) and free() is usually enough to find memory leaks. In C++
memory can be allocated and released by programs which contain none of
these functions (explicitly). Are there any switches in gcc, or in
other C++ compilers, that cause the compiler to route memory
manipulation through these routines, or in some similar way aid in
debugging memory issues?

windows provides building blocks to help you debug memory leaks.
Start here:-
"Debug Routines"
http://msdn.microsoft.com/en-us/library/1666sb98(v=vs.80).aspx

I found "hooking" the allocation routine gave the best results.

 

[Guest]

On Thu, 3 May 2012 05:03:53 -0700 (PDT),



His problem is that he's using mingw, so none of that is really
available to him. And there's no shortage of memory checking tools
that work with "native" Windows tools like MSVC anyway, if you'd
prefer to not roll your own.

this isn't a VCC thing its a windows thing. If he's doing any sort of windows programming then those debug functions are available. I always though it was a bit of a pain that microsoft didn't provide a proper tool rather than the bits to build the tool.

 

[Nobody]

While the MSVC CRT (whether that's part of Windows or not is at least
somewhat debatable) does include a fair number of debugging functions,
mingw does not use it, rather it supplies a CRT derived from the one
commonly used with *nix GCC implementations.

Windows and Linux use the term "CRT" differently. Linux uses it to refer
to the crt*.o files which are statically linked into every executable by
default. Windows uses it to refer to the standard library which provides
(amongst other things) the functions defined by the ISO C standard, i.e.
the Windows equivalent of Linux' "libc".

MinGW uses msvcrt.dll as its "libc".

However: it doesn't use different versions for "debug" and "release"
builds, and it uses a rather old version (i.e. msvcrt.dll rather than the
msvcr80.dll used in VS 2005, which is the version to which the link refers).

One thing to bear in mind with Windows is that each DLL specifies which
DLL provides an imported function. This can result in the EXE and
the various DLLs using different versions of MSVCRT. Each version has a
separate heap, so hooking malloc/free in one version won't catch
allocations from another version.

Also, what is allocated by one version must be freed by that version. If a
library function returns a pointer obtained from malloc(), the caller must
pass that pointer back to the original library to be freed; it can't just
pass it directly to free(), as the library and caller may be using
different versions of MSVCRT with different heaps.