Memory leak detection tools?

[kk_oop@yahoo.com]

Hi. Any recommendations for memory leak detection tools for C++ running
on Linux or Solaris? I'm interested in static (compile time) and
runtime detection. It's for a large project.

Thanks!

Ken

[Larry Smith]

Re: Memory leak detection tools?

kk_oop@yahoo.co m wrote:

Hi. Any recommendations for memory leak detection tools for C++ running
on Linux or Solaris? I'm interested in static (compile time) and
runtime detection. It's for a large project.
>
Thanks!
>
Ken
>

Try the newsgroup

comp.os.linux.d evelopment.syst em

[Jacek Dziedzic]

Re: Memory leak detection tools?

kk_oop@yahoo.co m wrote:

Hi. Any recommendations for memory leak detection tools for C++ running
on Linux or Solaris? I'm interested in static (compile time) and
runtime detection.

For runtime detection, without the need to recompile,
you might try valgrind, if it is supported on your platform.

It's for a large project.

That might be difficult -- programs run under valgrind
during debugging tend to consume memory and CPU power
in the order of ten times the original program.
But worth a try.

HTH,
- J.

[Ian Collins]

Re: Memory leak detection tools?

kk_oop@yahoo.co m wrote:

Hi. Any recommendations for memory leak detection tools for C++ running
on Linux or Solaris? I'm interested in static (compile time) and
runtime detection. It's for a large project.
>

Try comp.unix.progr ammer. Sun's dbx does the runtime part.

Use of your own operator new can also provide run time data.

--
Ian Collins.

[VJ]

Re: Memory leak detection tools?

Jacek Dziedzic wrote:

kk_oop@yahoo.co m wrote:
>

>Hi. Any recommendations for memory leak detection tools for C++ running
>on Linux or Solaris? I'm interested in static (compile time) and
>runtime detection.

>
>
For runtime detection, without the need to recompile,
you might try valgrind, if it is supported on your platform.

valgrind is supported on linux

>

>It's for a large project.

>
>
That might be difficult -- programs run under valgrind
during debugging tend to consume memory and CPU power
in the order of ten times the original program.
But worth a try.
>

If he makes small unit tests, he can use valgrind on those, and at the
same time test both unit tests and his code

I agree it is much slower then normal compilation

[Ian Collins]

Re: Memory leak detection tools?

VJ wrote:

>
If he makes small unit tests, he can use valgrind on those, and at the
same time test both unit tests and his code
>

If he has the good sense to produce decent unit tests, adding operator
new() and delete() to the test harness will serve him well. No need for
anything else.

--
Ian Collins.

[Jacek Dziedzic]

Re: Memory leak detection tools?

VJ wrote:

Jacek Dziedzic wrote:
>

>kk_oop@yahoo.co m wrote:
>>

>>Hi. Any recommendations for memory leak detection tools for C++ running
>>on Linux or Solaris? I'm interested in static (compile time) and
>>runtime detection.

>>
>>
>>
> For runtime detection, without the need to recompile,
>you might try valgrind, if it is supported on your platform.

>
>
valgrind is supported on linux

Yes, but not for all architectures, like IA-64, for instance.

- J.

[VJ]

Re: Memory leak detection tools?

Ian Collins wrote:

VJ wrote:
>

>>If he makes small unit tests, he can use valgrind on those, and at the
>>same time test both unit tests and his code
>>

>
If he has the good sense to produce decent unit tests, adding operator
new() and delete() to the test harness will serve him well. No need for
anything else.
>

Shit happens, cause noone is perfect, therefore testing for memory leaks
in unit tests is not bad, just takes time and should not be used often.

Murphies law rules everywhere ;)

[Ian Collins]

Re: Memory leak detection tools?

VJ wrote:

Ian Collins wrote:
>

>VJ wrote:
>>

>>If he makes small unit tests, he can use valgrind on those, and at the
>>same time test both unit tests and his code
>>>

>>
>If he has the good sense to produce decent unit tests, adding operator
>new() and delete() to the test harness will serve him well. No need for
>anything else.
>>

>
Shit happens, cause noone is perfect, therefore testing for memory leaks
in unit tests is not bad, just takes time and should not be used often.
>

I think you miss my point, if you provide your own memory manager, you
can have memory leak detection almost free, just by keeping tabs on all
allocated blocks.

The same applies with Sun's dbx, there is next to no overhead running
with memory leak detection enabled. Access violation detection is an
other story.

--
Ian Collins.