«

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

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

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.

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.programmer. Sun's dbx does the runtime part.

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

--
Ian Collins.

Jacek Dziedzic wrote:
> 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

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.

VJ wrote:
> Jacek Dziedzic wrote:
>
>> 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.

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

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

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