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

[Nelson Davenapalli]

What are the best ways of debugging your c++ program.

 

[Eldar Zakirov]

For detecting memory leaks I use Valgrind.

 

[Jorgen Grahn]

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

 

[Ian Collins]

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.

 

[Juha Nieminen]

Using a debugger works reasonably well.

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

 

[gwowen]

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.

 

[Ian Collins]

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]

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.

 

[gwowen]

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

 

[Jorgen Grahn]

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

 

[Ian Collins]

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

 

[gwowen]

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

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?

 

[Ian Collins]

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


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

 

[Guest]

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

develop a mathematical proof that your program doesn't leak resources.

 

[Guest]

please include your question in the body of your post

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?

 

[Jorgen Grahn]

On 05/25/12 09:10 PM, gwowen wrote: .... ....

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

 

[Juha Nieminen]

"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).

 

[jack.sanga]

If you are running in the windows visual studio environment
take a look at "Visual Leak Detector".

 

[Ian Collins]

The last updates on those files were in 2001!

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.

 

[Juha Nieminen]

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.