C++ Memory Profiling/Debugging

[David Carter-Hitchin]

Hi Lou,

Thanks - I'll give it a spin.  I read with some reservation on
http://dmalloc.com/:

"Dmalloc is not as good with C++ as C because the dynamic memory routines
in C++ are new() and delete() as opposed to malloc() and free(). Since new
and delete are usually not used as functions but rather as x = new type,
there is no easy way for dmalloc to pass in file and line information
unfortunately. The `libdmallocxx.a' library provides the file
`dmallocc.cc' which effectively redirects new to the more familiar malloc
and delete to the more familiar free."

I'll give it a go anyway.

Wonder if there is a C++ friendly debug tool out there...

Thanks,
David

On Sat, 21 Feb 2004, Louis LeBlanc wrote:

> On 02/21/04 12:48 AM, David Carter-Hitchin sat at the `puter and typed:
> > Hi,
> >
> > Does anyone out there know a good C++ memory profiling/debugging tool for
> > FBSD?  I'm looking for a tool like valgrind or purify.  I grepped around
> > in the ports directory and I found "ElectricFence" and "mprof" but these
> > seem to be for C only (as they refer exclusively to malloc & free).
> > "bohem-gc" sounds like the kind of package I'm after - but I thought I ask
> > in case anyone has better ideas... ?
>
> devel/dmalloc is pretty good.  I'm using it with C on Solaris, but all
> you do is basically link its library into your process, set a few
> environment variables, and it will dump a complete list of statistics,
> based on the values of the environment variables.  The most valuable
> statistic is the origin of every single memory allocation that is not
> freed.  Simply track those made by your code (file name and line
> number of the malloc are given) and fix them.  I found it MUCH easier
> to integrate and use than Efence or Purify.
>
> If your process dynamically allocates memory that isn't intended to be
> freed, like for internal structure allocation through the life of the
> process, you might include a routine that frees such pointers in your
> cleanup process.  I have a number of things I have to clear that
> aren't intended to be freed during the life of the process, so I
> simply added them within a conditional precompiler block that only
> gets compiled when I'm building a memory debuggable version.
>
> You wouldn't believe the memory leaks I found in (someone else's)
> production code with this tool.  HIGHLY recommended.
>
> Good luck.
>
> > Please cc me on any replies - I had to drop out of this list sometime ago
> > as the sheer volume was killing my mailbox...
>
> I know what you mean . . .
>
> Lou
> --
> Louis LeBlanc               leblanc at keyslapper.org
> Fully Funded Hobbyist, KeySlapper Extrordinaire :)
> http://www.keyslapper.org                     Ô¿Ô¬
>
> Unless hours were cups of sack, and minutes capons, and clocks the tongues
> of bawds, and dials the signs of leaping houses, and the blessed sun himself
> a fair, hot wench in flame-colored taffeta, I see no reason why thou shouldst
> be so superfluous to demand the time of the day.  I wasted time and now doth
> time waste me.
>     -- William Shakespeare
>
>