what is the best way to identify memory leaks in a C++ code.

Discussion in 'C++' started by Nelson Davenapalli, May 23, 2012.

  1. What are the best ways of debugging your c++ program.
    Nelson Davenapalli, May 23, 2012
    #1
    1. Advertising

  2. For detecting memory leaks I use Valgrind.
    Eldar Zakirov, May 24, 2012
    #2
    1. Advertising

  3. Nelson Davenapalli

    Jorgen Grahn Guest

    On Wed, 2012-05-23, Nelson Davenapalli wrote:

    > Subject: Re: what is the best way to identify memory leaks in a C++ code.
    > What are the best ways of debugging your c++ program.


    Which of the two questions do you want answers to? Both?
    In which context?

    /Jorgen

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

    Ian Collins Guest

    On 05/24/12 07:05 AM, Nelson Davenapalli wrote:
    > What are the best ways of debugging your c++ program.


    Using a debugger works reasonably well.

    Writing your tests before you code is better still.

    --
    Ian Collins
    Ian Collins, May 24, 2012
    #4
  5. Ian Collins <> wrote:
    > On 05/24/12 07:05 AM, Nelson Davenapalli wrote:
    >> What are the best ways of debugging your c++ program.

    >
    > Using a debugger works reasonably well.


    Most debuggers don't detect memory leaks. You need a specialized tool
    for that such as valgrind.
    Juha Nieminen, May 24, 2012
    #5
  6. Nelson Davenapalli

    gwowen Guest

    On May 24, 9:14 am, Ian Collins <> wrote:

    > Writing your tests before you code is better still.


    Unit tests are great but...

    In my experience, it's far more tricky to write (and utilise) unit
    tests for memory usage than for most other sorts of correctness (i.e.
    "did I get the correct answer?"). It's certainly not impossible
    because
    i) "slow puncture" memory leaks may well not leak noticeable amounts
    of memory in hourly time periods. In my experience unit test work
    best when couple to a fast code-compile-test cycle. (Of course, a
    valgrind run is not exactly lightning fast).
    ii) changing an algorithm (say) may well take a lot more than the
    previous one [one may be trading memory for speed, say]. It's hard to
    say what it means for a unit test to fail in this case.
    gwowen, May 24, 2012
    #6
  7. Nelson Davenapalli

    Ian Collins Guest

    On 05/25/12 01:21 AM, Juha Nieminen wrote:
    > Ian Collins<> wrote:
    >> On 05/24/12 07:05 AM, Nelson Davenapalli wrote:
    >>> What are the best ways of debugging your c++ program.

    >>
    >> Using a debugger works reasonably well.

    >
    > Most debuggers don't detect memory leaks. You need a specialized tool
    > for that such as valgrind.


    I was answering the question above, I didn't notice there was anther in
    the subject! Anyway, the debugger I typically use (dbx) does memory
    access and leak checking.

    --
    Ian Collins
    Ian Collins, May 24, 2012
    #7
  8. Nelson Davenapalli

    Ian Collins Guest

    On 05/25/12 02:34 AM, gwowen wrote:
    > On May 24, 9:14 am, Ian Collins<> wrote:
    >
    >> Writing your tests before you code is better still.

    >
    > Unit tests are great but...
    >
    > In my experience, it's far more tricky to write (and utilise) unit
    > tests for memory usage than for most other sorts of correctness (i.e.
    > "did I get the correct answer?"). It's certainly not impossible
    > because
    > i) "slow puncture" memory leaks may well not leak noticeable amounts
    > of memory in hourly time periods. In my experience unit test work
    > best when couple to a fast code-compile-test cycle. (Of course, a
    > valgrind run is not exactly lightning fast).


    I run tests with a custom allocator that can be checked in the test
    tearDown. Once in a while (before sharing my changes) I run them in the
    debugger with access checking enabled.

    --
    Ian Collins
    Ian Collins, May 24, 2012
    #8
  9. Nelson Davenapalli

    gwowen Guest

    On May 24, 8:19 pm, Ian Collins <> wrote:

    > I run tests with a custom allocator that can be checked in the test
    > tearDown.  Once in a while (before sharing my changes) I run them in the
    > debugger with access checking enabled.


    Oh, OK, that makes sense. But unfortunately, the process now starts
    "First write your custom allocator...".

    I guess the obvious middle-ground is to use the valgrind hooks instead
    of a custom allocator, and have a unit test in the form of "valgrind
    run doesn't report any memory leaks".
    gwowen, May 25, 2012
    #9
  10. Nelson Davenapalli

    Jorgen Grahn Guest

    On Fri, 2012-05-25, gwowen wrote:
    > On May 24, 8:19 pm, Ian Collins <> wrote:
    >
    >> I run tests with a custom allocator that can be checked in the test
    >> tearDown.  Once in a while (before sharing my changes) I run them in the
    >> debugger with access checking enabled.

    >
    > Oh, OK, that makes sense. But unfortunately, the process now starts
    > "First write your custom allocator...".
    >
    > I guess the obvious middle-ground is to use the valgrind hooks instead
    > of a custom allocator, and have a unit test in the form of "valgrind
    > run doesn't report any memory leaks".


    I always set up my projects so 'make check' runs the unit tests as
    they are, and 'make checkv' runs them under valgrind. (But now that you
    mention it, I probably don't enable the leak checking -- hm ...)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 25, 2012
    #10
  11. Nelson Davenapalli

    Ian Collins Guest

    On 05/25/12 07:52 PM, gwowen wrote:
    > On May 24, 8:19 pm, Ian Collins<> wrote:
    >
    >> I run tests with a custom allocator that can be checked in the test
    >> tearDown. Once in a while (before sharing my changes) I run them in the
    >> debugger with access checking enabled.

    >
    > Oh, OK, that makes sense. But unfortunately, the process now starts
    > "First write your custom allocator...".


    The last updates on those files were in 2001!

    > I guess the obvious middle-ground is to use the valgrind hooks instead
    > of a custom allocator, and have a unit test in the form of "valgrind
    > run doesn't report any memory leaks".


    Assuming Linux, which I don't use....

    --
    Ian Collins
    Ian Collins, May 25, 2012
    #11
  12. Nelson Davenapalli

    gwowen Guest

    On May 25, 9:33 am, Ian Collins <> wrote:
    > On 05/25/12 07:52 PM, gwowen wrote:
    >
    > > On May 24, 8:19 pm, Ian Collins<>  wrote:

    >
    > >> I run tests with a custom allocator that can be checked in the test
    > >> tearDown.  Once in a while (before sharing my changes) I run them inthe
    > >> debugger with access checking enabled.

    >
    > > Oh, OK, that makes sense.  But unfortunately, the process now starts
    > > "First write your custom allocator...".

    >
    > The last updates on those files were in 2001!


    Well, sure, its the perfect candidate for code resuse, but that
    doesn't help until you've actually put the legwork in first (even if
    it was 11 years ago).

    > > I guess the obvious middle-ground is to use the valgrind hooks instead
    > > of a custom allocator, and have a unit test in the form of "valgrind
    > > run doesn't report any memory leaks".

    >
    > Assuming Linux, which I don't use....


    "Valgrind" here can be considered a placeholder for "widely available
    memory leak detector". Purify, maybe. :)

    Out of interest, can your custom allocator detect malloc'd pointers
    that have been lost (like a GC, say), or just those that are un-free'd
    at teardown?
    gwowen, May 25, 2012
    #12
  13. Nelson Davenapalli

    Ian Collins Guest

    On 05/25/12 09:10 PM, gwowen wrote:
    > On May 25, 9:33 am, Ian Collins<> wrote:
    >> On 05/25/12 07:52 PM, gwowen wrote:
    >>
    >>> On May 24, 8:19 pm, Ian Collins<> wrote:

    >>
    >>>> I run tests with a custom allocator that can be checked in the test
    >>>> tearDown. Once in a while (before sharing my changes) I run them in the
    >>>> debugger with access checking enabled.

    >>
    >>> Oh, OK, that makes sense. But unfortunately, the process now starts
    >>> "First write your custom allocator...".

    >>
    >> The last updates on those files were in 2001!

    >
    > Well, sure, its the perfect candidate for code resuse, but that
    > doesn't help until you've actually put the legwork in first (even if
    > it was 11 years ago).
    >
    >>> I guess the obvious middle-ground is to use the valgrind hooks instead
    >>> of a custom allocator, and have a unit test in the form of "valgrind
    >>> run doesn't report any memory leaks".

    >>
    >> Assuming Linux, which I don't use....

    >
    > "Valgrind" here can be considered a placeholder for "widely available
    > memory leak detector". Purify, maybe. :)
    >
    > Out of interest, can your custom allocator detect malloc'd pointers
    > that have been lost (like a GC, say), or just those that are un-free'd
    > at teardown?


    Just not freed and double freed.

    I must admit I don't use it much with new code where every pointer is
    owned by an object that looks after it.

    --
    Ian Collins
    Ian Collins, May 25, 2012
    #13
  14. Nelson Davenapalli

    Guest

    On Wednesday, May 23, 2012 8:05:00 PM UTC+1, Nelson Davenapalli wrote:

    > what is the best way to identify memory leaks in a C++ code.


    develop a mathematical proof that your program doesn't leak resources.
    , May 25, 2012
    #14
  15. Nelson Davenapalli

    Guest

    please include your question in the body of your post

    On Wednesday, May 23, 2012 8:05:00 PM UTC+1, Nelson Davenapalli wrote:

    > what is the best way to identify memory leaks in a C++ code[?]


    you could over-ride new and delete and keep a list of all allocations including file and line allocated. After a suspect operation dump the list and see what's unexpectedly still in the list. I've also resorted to counting CTOR and DTOR calls for suspect objects. Discovered one program that communicated via TCP/IP never deleted any transmitted message!

    Are you using RAII?
    , May 25, 2012
    #15
  16. Nelson Davenapalli

    Jorgen Grahn Guest

    On Fri, 2012-05-25, Ian Collins wrote:
    > On 05/25/12 09:10 PM, gwowen wrote:

    ....
    >> Out of interest, can your custom allocator detect malloc'd pointers
    >> that have been lost (like a GC, say), or just those that are un-free'd
    >> at teardown?

    ....

    > I must admit I don't use it much with new code where every pointer is
    > owned by an object that looks after it.


    And that brings us to another answer to "what is the best way to
    identify memory leaks in a C++ code": use the language so that memory
    leaks are unlikely to happen. Usually not hard to do in C++.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 25, 2012
    #16
  17. gwowen <> wrote:
    > "Valgrind" here can be considered a placeholder for "widely available
    > memory leak detector". Purify, maybe. :)


    Last I checked (although this was some years ago), valgrind is the
    only free tool available for this, and it works only on unixes. (I don't
    know if any serious effort has been made to port it to Windows and support
    eg. Visual Studio projects.)

    The only other tool I have ever tested (on Windows) is AQTime, which
    main purpose is to be a performance profiler, but which also detects leaks
    and out-of-bounds accesses. Seemed to work pretty well, but is commercial
    (or at least was when I last checked).
    Juha Nieminen, May 25, 2012
    #17
  18. Nelson Davenapalli

    Guest

    If you are running in the windows visual studio environment
    take a look at "Visual Leak Detector".
    , May 25, 2012
    #18
  19. Nelson Davenapalli

    Ian Collins Guest

    On 05/26/12 04:11 PM, William Ahern wrote:
    > Ian Collins<> wrote:
    >> On 05/25/12 07:52 PM, gwowen wrote:
    >>> On May 24, 8:19 pm, Ian Collins<> wrote:
    >>>
    >>>> I run tests with a custom allocator that can be checked in the test
    >>>> tearDown. Once in a while (before sharing my changes) I run them in the
    >>>> debugger with access checking enabled.
    >>>
    >>> Oh, OK, that makes sense. But unfortunately, the process now starts
    >>> "First write your custom allocator...".

    >
    >> The last updates on those files were in 2001!

    >
    >>> I guess the obvious middle-ground is to use the valgrind hooks instead
    >>> of a custom allocator, and have a unit test in the form of "valgrind
    >>> run doesn't report any memory leaks".

    >
    >> Assuming Linux, which I don't use....

    >
    > It works on OS X now, too. Although there have been some glitches with Lion.
    > Still, it's [theoretically] maintained and on equal footing with Linux.
    >
    > But maybe you're referring to Solaris or Windows or z/OS....


    Solaris, where the native debugger does most of what valgrind offers.

    --
    Ian Collins
    Ian Collins, May 26, 2012
    #19
  20. wrote:
    > If you are running in the windows visual studio environment
    > take a look at "Visual Leak Detector".


    Deducing from its description, it doesn't detect out-of-bounds
    accesses.
    Juha Nieminen, May 26, 2012
    #20
    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. Replies:
    2
    Views:
    613
    Curt_C [MVP]
    Jul 27, 2004
  2. LinuxGuy

    Will this code leaks memory

    LinuxGuy, May 10, 2006, in forum: C++
    Replies:
    5
    Views:
    263
    Christopher Benson-Manica
    May 12, 2006
  3. Jason Burr

    Best Way To Identify User / Shopping Cart

    Jason Burr, Dec 9, 2003, in forum: ASP General
    Replies:
    4
    Views:
    184
    Aaron Bertrand - MVP
    Dec 9, 2003
  4. Sven C. Koehler
    Replies:
    6
    Views:
    102
    Nobuyoshi Nakada
    Aug 20, 2008
  5. Replies:
    4
    Views:
    110
Loading...

Share This Page