Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

86 views
Skip to first unread message

Nelson Davenapalli

unread,
May 23, 2012, 3:05:00 PM5/23/12
to
What are the best ways of debugging your c++ program.

Eldar Zakirov

unread,
May 24, 2012, 12:56:24 AM5/24/12
to
For detecting memory leaks I use Valgrind.

Jorgen Grahn

unread,
May 24, 2012, 3:53:36 AM5/24/12
to
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 .

Ian Collins

unread,
May 24, 2012, 4:14:01 AM5/24/12
to
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

Juha Nieminen

unread,
May 24, 2012, 9:21:29 AM5/24/12
to
Ian Collins <ian-...@hotmail.com> 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.

gwowen

unread,
May 24, 2012, 10:34:50 AM5/24/12
to
On May 24, 9:14 am, Ian Collins <ian-n...@hotmail.com> 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.

Ian Collins

unread,
May 24, 2012, 3:16:25 PM5/24/12
to
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

unread,
May 24, 2012, 3:19:57 PM5/24/12
to
On 05/25/12 02:34 AM, gwowen wrote:
> On May 24, 9:14 am, Ian Collins<ian-n...@hotmail.com> 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

gwowen

unread,
May 25, 2012, 3:52:43 AM5/25/12
to
On May 24, 8:19 pm, Ian Collins <ian-n...@hotmail.com> 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".

Jorgen Grahn

unread,
May 25, 2012, 4:09:03 AM5/25/12
to
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 ...)

Ian Collins

unread,
May 25, 2012, 4:33:28 AM5/25/12
to
On 05/25/12 07:52 PM, gwowen wrote:
> On May 24, 8:19 pm, Ian Collins<ian-n...@hotmail.com> 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

gwowen

unread,
May 25, 2012, 5:10:31 AM5/25/12
to
On May 25, 9:33 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 05/25/12 07:52 PM, gwowen wrote:
>
> > On May 24, 8:19 pm, Ian Collins<ian-n...@hotmail.com>  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?

Ian Collins

unread,
May 25, 2012, 5:29:42 AM5/25/12
to
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

nick_keigh...@hotmail.com

unread,
May 25, 2012, 5:49:03 AM5/25/12
to
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.

nick_keigh...@hotmail.com

unread,
May 25, 2012, 6:00:08 AM5/25/12
to
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?

Jorgen Grahn

unread,
May 25, 2012, 6:41:07 AM5/25/12
to
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++.

Juha Nieminen

unread,
May 25, 2012, 11:35:52 AM5/25/12
to
gwowen <gwo...@gmail.com> 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).

jack....@perkinelmer.com

unread,
May 25, 2012, 5:52:01 PM5/25/12
to
If you are running in the windows visual studio environment
take a look at "Visual Leak Detector".

William Ahern

unread,
May 26, 2012, 12:11:00 AM5/26/12
to
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....

Ian Collins

unread,
May 26, 2012, 1:17:12 AM5/26/12
to
Solaris, where the native debugger does most of what valgrind offers.

--
Ian Collins

Juha Nieminen

unread,
May 26, 2012, 1:12:41 PM5/26/12
to
jack....@perkinelmer.com 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.
0 new messages