Memory Leak Detection

Discussion in 'C++' started by Christopher, Sep 13, 2011.

  1. Christopher

    Christopher Guest

    Since this isn't a language question, it is probably OT, so I request
    some redirection if that is the case.

    I'm working on some code that obviously has a giant leak or many small
    leaks. Since the code is fairly large in size, it isn't easy to make a
    guess on where the leak is.

    What procedure do you use to hunt down leaks?

    The usual suspect of doing a new without a corresponding delete is
    easy enough to find, but we have harder problems like resources not
    getting destroyed on exception or deconstruction of dependends. I've
    also got COM stuff in the mix. The software I've tried so far doesn't
    seem to point to anything that is an actual leak, but gives millions
    of false positives to wade through, wasting expensive man hours.
    Christopher, Sep 13, 2011
    #1
    1. Advertising

  2. Christopher

    Noah Roberts Guest

    On Sep 13, 8:55 am, Christopher <> wrote:
    > The software I've tried so far doesn't
    > seem to point to anything that is an actual leak, but gives millions
    > of false positives to wade through, wasting expensive man hours.


    This is what memory leaks do. This is why you should be using RAII
    objects so that exceptions don't skip deletions.

    AQtime does OK. No leak detection software is perfect though.
    Noah Roberts, Sep 13, 2011
    #2
    1. Advertising

  3. Christopher

    Guest

    On Sep 13, 11:55 am, Christopher <> wrote:
    > Since this isn't a language question, it is probably OT, so I request
    > some redirection if that is the case.
    >
    > I'm working on some code that obviously has a giant leak or many small
    > leaks. Since the code is fairly large in size, it isn't easy to make a
    > guess on where the leak is.
    >
    > What procedure do you use to hunt down leaks?
    >
    > The usual suspect of doing a new without a corresponding delete is
    > easy enough to find, but we have harder problems like resources not
    > getting destroyed on exception or deconstruction of dependends. I've
    > also got COM stuff in the mix. The software I've tried so far doesn't
    > seem to point to anything that is an actual leak, but gives millions
    > of false positives to wade through, wasting expensive man hours.


    On Linux, I've used valgrind to track down memory leaks. It's very
    good and it cost nothing.

    It is well worth the time investment (1/2 day) to learn how to use
    it. After that, you will be pleasantly surprised at what it catches -
    both large and small issues.

    As an added benefit, it uses your currently compiled executable. With
    some memory leak detectors, you have to recompile or relink your
    application.

    HTH
    , Sep 13, 2011
    #3
  4. Christopher

    Miles Bader Guest

    "" <> writes:
    > On Linux, I've used valgrind to track down memory leaks. It's very
    > good and it cost nothing.
    >
    > It is well worth the time investment (1/2 day) to learn how to use
    > it. After that, you will be pleasantly surprised at what it catches -
    > both large and small issues.


    Yes, valgrind is an insanely great tool.

    Not only is it super useful in tracking down the cause of bugs that
    manifest elsewhere, it allows one to be proactive and find many
    obscure subtle bugs that _haven't_ manifested elsewhere -- all without
    much user effort!

    [Running valgrind on a program for the first time can be a rude shock
    though, revealing tons of little bugs that you never noticed before!]

    -Miles

    --
    Electricity, n. The cause of all natural phenomena not known to be caused by
    something else.
    Miles Bader, Sep 14, 2011
    #4
  5. Miles Bader <> wrote:
    > [Running valgrind on a program for the first time can be a rude shock
    > though, revealing tons of little bugs that you never noticed before!]


    Actually if you have followed the basic rules of RAII and all the
    rules that naturally follow from it (such as the so-called rule of
    three, never use a raw 'new', use the STL whenever it's suitable, and
    so on), such bugs become rarer and rarer.

    In fact, I don't even remember when was the last time I had a memory
    leak (or access to a deleted object) in a program of mine. It must be
    at least 10 years. The most common problem has been those pesky off-by-1
    errors. In most cases this is caught by compiling in debug mode (eg. in
    gcc using the _GLIBCXX_DEBUG preprocessor macro definition).
    Juha Nieminen, Sep 14, 2011
    #5
  6. Christopher

    Miles Bader Guest

    Juha Nieminen <> writes:
    > Miles Bader <> wrote:
    >> [Running valgrind on a program for the first time can be a rude shock
    >> though, revealing tons of little bugs that you never noticed before!]

    >
    > Actually if you have followed the basic rules of RAII and all the
    > rules that naturally follow from it (such as the so-called rule of
    > three, never use a raw 'new', use the STL whenever it's suitable,
    > and so on), such bugs become rarer and rarer.


    Sure, I do follow those guidelines -- and indeed they help greatly
    (I've found my programs in "proper" C++ to be much less buggy than my
    programs in C, or in "non-proper" C++) -- but nonetheless, in any
    non-trivial program, bugs are present, and valgrind is a _very_ useful
    tool for finding many of them.

    -Miles

    --
    If you can't beat them, arrange to have them beaten. [George Carlin]
    Miles Bader, Sep 14, 2011
    #6
  7. Christopher

    Goran Guest

    On Sep 13, 5:55 pm, Christopher <> wrote:
    > Since this isn't a language question, it is probably OT, so I request
    > some redirection if that is the case.
    >
    > I'm working on some code that obviously has a giant leak or many small
    > leaks. Since the code is fairly large in size, it isn't easy to make a
    > guess on where the leak is.
    >
    > What procedure do you use to hunt down leaks?
    >
    > The usual suspect of doing a new without a corresponding delete is
    > easy enough to find, but we have harder problems like resources not
    > getting destroyed on exception or deconstruction of dependends. I've
    > also got COM stuff in the mix. The software I've tried so far doesn't
    > seem to point to anything that is an actual leak, but gives millions
    > of false positives to wade through, wasting expensive man hours.


    If you have COM, you're likely with Visual Studio. If so, doesn't
    debug CRT help? It's memory leak tracing capabilities are OK.

    For COM, you need a windows-specific tool. I would be surprised if
    they didn't employ COM-related memory leak hunting techniques.

    Finally, how do you make sure that your false positives indeed are
    false? I mean, if you have __millions__ of false positives, there's
    something seriously wrong. I find it hard to believe that any tool is
    __that__ bad.

    Goran.
    Goran, Sep 14, 2011
    #7
  8. Christopher

    Ian Collins Guest

    On 09/14/11 06:06 PM, Juha Nieminen wrote:
    > Miles Bader<> wrote:
    >> [Running valgrind on a program for the first time can be a rude shock
    >> though, revealing tons of little bugs that you never noticed before!]

    >
    > Actually if you have followed the basic rules of RAII and all the
    > rules that naturally follow from it (such as the so-called rule of
    > three, never use a raw 'new', use the STL whenever it's suitable, and
    > so on), such bugs become rarer and rarer.


    The most recent one I found (using dbx, not valgrind) was a bug in a
    system library flushed out by me using RAII to match library allocations
    and deallocations. With the "proper" code I got duplicate free errors
    and without it I got a memory leak! In the end I settled for the leak
    and a bug report.

    --
    Ian Collins
    Ian Collins, Sep 14, 2011
    #8
  9. Christopher

    Christopher Guest

    On Sep 14, 2:38 am, Goran <> wrote:
    > On Sep 13, 5:55 pm, Christopher <> wrote:
    >
    > > Since this isn't a language question, it is probably OT, so I request
    > > some redirection if that is the case.

    >
    > > I'm working on some code that obviously has a giant leak or many small
    > > leaks. Since the code is fairly large in size, it isn't easy to make a
    > > guess on where the leak is.

    >
    > > What procedure do you use to hunt down leaks?

    >
    > > The usual suspect of doing a new without a corresponding delete is
    > > easy enough to find, but we have harder problems like resources not
    > > getting destroyed on exception or deconstruction of dependends. I've
    > > also got COM stuff in the mix. The software I've tried so far doesn't
    > > seem to point to anything that is an actual leak, but gives millions
    > > of false positives to wade through, wasting expensive man hours.

    >
    > If you have COM, you're likely with Visual Studio. If so, doesn't
    > debug CRT help? It's memory leak tracing capabilities are OK.


    No, it didn't point anything out.


    > Finally, how do you make sure that your false positives indeed are
    > false?


    Using Intel Parrallel studio currently...
    By looking at them one by one. Where was it allocated? Where was it
    released? Did the release occur?
    More often then not it points to code below the Windows API that I
    don't have access to. I crawl up the call stack and take a look at
    what call in the source started it. Its usually a one line Windows API
    call. Best I can do is make sure it matches the MSDN, that there
    weren't any nuances about the call, etc. I can't do anything about
    what Windows does under the hood. So, I might try to make a small test
    and write a similar chunk of code and run it over 1000s of iterations
    while watching process explorer to see if memory usage goes up.



    > I mean, if you have __millions__ of false positives, there's
    > something seriously wrong. I find it hard to believe that any tool is
    > __that__ bad.


    There is something seriously wrong with the code...I didn't write
    it :)
    Christopher, Sep 14, 2011
    #9
  10. Christopher

    Marc Guest

    Juha Nieminen wrote:

    > Miles Bader <> wrote:
    >> [Running valgrind on a program for the first time can be a rude shock
    >> though, revealing tons of little bugs that you never noticed before!]


    Too bad some of its limitations make it unusable for some code
    (non-default rounding modes are useless to most people but essential
    to others). (note: that does mean I find it great already)

    > Actually if you have followed the basic rules of RAII and all the
    > rules that naturally follow from it (such as the so-called rule of
    > three, never use a raw 'new', use the STL whenever it's suitable, and
    > so on), such bugs become rarer and rarer.
    >
    > In fact, I don't even remember when was the last time I had a memory
    > leak (or access to a deleted object) in a program of mine. It must be
    > at least 10 years. The most common problem has been those pesky off-by-1
    > errors. In most cases this is caught by compiling in debug mode (eg. in
    > gcc using the _GLIBCXX_DEBUG preprocessor macro definition).


    In multi-threaded contexts, things can be a bit more complicated, with
    a thread destroying an object before another thread is done using it
    or stranger things. I am not saying there aren't good practices for
    these too, but they may be less intuitive, less known, and harder to
    notice when you parallelize existing code. Which makes observing tools
    very useful, when they don't hide the errors...
    Marc, Sep 14, 2011
    #10
  11. Christopher

    Goran Guest

    On Sep 14, 5:22 pm, Christopher <> wrote:
    > Using Intel Parrallel studio currently...
    > By looking at them one by one. Where was it allocated? Where was it
    > released? Did the release occur?
    > More often then not it points to code below the Windows API that I
    > don't have access to. I crawl up the call stack and take a look at
    > what call in the source started it. Its usually a one line Windows API
    > call.


    Like SysAllocString, CoTaskMemAlloc or calls to IMalloc? If so, you
    might have bad memory management on COM boundaries. These can be
    tricky. Can you make an example where the tool gives you a presumably
    false leak?

    Goran.
    Goran, Sep 15, 2011
    #11
  12. Christopher

    Christopher Guest

    On Sep 15, 3:09 am, Goran <> wrote:
    > On Sep 14, 5:22 pm, Christopher <> wrote:
    >
    > > Using Intel Parrallel studio currently...
    > > By looking at them one by one. Where was it allocated? Where was it
    > > released? Did the release occur?
    > > More often then not it points to code below the Windows API that I
    > > don't have access to. I crawl up the call stack and take a look at
    > > what call in the source started it. Its usually a one line Windows API
    > > call.

    >
    > Like SysAllocString, CoTaskMemAlloc or calls to IMalloc? If so, you
    > might have bad memory management on COM boundaries. These can be
    > tricky. Can you make an example where the tool gives you a presumably
    > false leak?
    >
    > Goran.


    I have since switched to trying to learn AQTime and am going through
    the eval version. So, from memory, it was pointing to _bstr_t
    allocations, ATL functions that converted unicode to multibyte or vica
    versa, to name a couple.

    I haven't gotten any results with AQTime either. We seem to have a
    problem where the COM service goes into deadlock and will not exit
    with AQTime running it. I'll have to visit their forums and see if I
    can work it out.
    Christopher, Sep 16, 2011
    #12
    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. __jakal__

    c++ memory leak detection

    __jakal__, Apr 28, 2004, in forum: C++
    Replies:
    9
    Views:
    5,072
    StarDrago
    May 24, 2012
  2. Spur
    Replies:
    1
    Views:
    401
    Howard Hinnant
    May 9, 2004
  3. Winbatch

    Memory Leak Detection

    Winbatch, Feb 23, 2005, in forum: C++
    Replies:
    11
    Views:
    8,286
    NitinTheEmbeddedFreak
    Apr 15, 2009
  4. mosaic

    About memory leak detection.

    mosaic, Jul 15, 2004, in forum: C Programming
    Replies:
    7
    Views:
    368
    Bernhard
    Jul 16, 2004
  5. Replies:
    8
    Views:
    988
    Ian Collins
    Nov 3, 2006
Loading...

Share This Page