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 [EMAIL PROTECTED]
> 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
>
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
