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]"