Compiler switches to ease memory debugging in C++ ?

Discussion in 'C++' started by mathog, May 1, 2012.

  1. mathog

    mathog 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?

    Thank you,

    David Mathog
     
    mathog, May 1, 2012
    #1
    1. Advertising

  2. On 5/1/2012 1:22 PM, mathog wrote:
    > 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
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, May 1, 2012
    #2
    1. Advertising

  3. mathog

    Jorgen Grahn Guest

    On Tue, 2012-05-01, Robert Wessel wrote:
    > On Tue, 01 May 2012 10:22:01 -0700, mathog <> wrote:
    >
    >>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?

    >
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 1, 2012
    #3
  4. mathog

    mathog Guest

    Jorgen Grahn wrote:
    > 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.
     
    mathog, May 1, 2012
    #4
  5. mathog

    Jorgen Grahn Guest

    On Tue, 2012-05-01, mathog wrote:
    > Jorgen Grahn wrote:
    >> OP: do you have some practical reason to worry?

    >
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 1, 2012
    #5
  6. On May 1, 2:33 pm, mathog <> wrote:
    > Jorgen Grahn wrote:
    > > 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.


    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.
     
    Joshua Maurice, May 2, 2012
    #6
  7. mathog

    Guest

    On Tuesday, May 1, 2012 6:22:01 PM UTC+1, mathog wrote:

    > 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.
     
    , May 3, 2012
    #7
  8. mathog

    Guest

    On Thursday, May 3, 2012 5:48:50 PM UTC+1, wrote:
    > On Thu, 3 May 2012 05:03:53 -0700 (PDT),
    > wrote:
    >
    > >On Tuesday, May 1, 2012 6:22:01 PM UTC+1, mathog wrote:
    > >
    > >> 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.

    >
    >
    > 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.
     
    , May 4, 2012
    #8
  9. mathog

    Nobody Guest

    On Fri, 04 May 2012 22:22:38 -0500, Robert Wessel wrote:

    > 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.
     
    Nobody, May 5, 2012
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kelsey Bjarnason

    Ease of use...

    Kelsey Bjarnason, Jul 4, 2003, in forum: C Programming
    Replies:
    5
    Views:
    938
    Kelsey Bjarnason
    Jul 5, 2003
  2. Replies:
    1
    Views:
    317
    Edward Diener
    Apr 27, 2007
  3. bwv549
    Replies:
    4
    Views:
    184
    bwv549
    May 26, 2010
  4. teppic.xxviii

    Debug javascript with ease!

    teppic.xxviii, Jun 21, 2007, in forum: Javascript
    Replies:
    13
    Views:
    208
  5. gleery
    Replies:
    4
    Views:
    109
    Dr J R Stockton
    Jul 25, 2008
Loading...

Share This Page