Date: Sun, 22 Feb 2004 10:56:42 +0000 (GMT) From: David Carter-Hitchin <david@carter-hitchin.clara.co.uk> To: freebsd-questions@freebsd.org Subject: Re: C++ Memory Profiling/Debugging Message-ID: <20040222105343.R29625@stoat.clara.net> In-Reply-To: <20040221230536.GA38823@keyslapper.org> References: <20040221004102.M268@stoat.clara.net> <20040221230536.GA38823@keyslapper.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D 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 f= or > > FBSD? I'm looking for a tool like valgrind or purify. I grepped aroun= d > > in the ports directory and I found "ElectricFence" and "mprof" but thes= e > > 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 a= go > > as the sheer volume was killing my mailbox... > > I know what you mean . . . > > Lou > -- > Louis LeBlanc leblanc@keyslapper.org > Fully Funded Hobbyist, KeySlapper Extrordinaire :) > http://www.keyslapper.org =D4=BF=D4=AC > > Unless hours were cups of sack, and minutes capons, and clocks the tongue= s > of bawds, and dials the signs of leaping houses, and the blessed sun hims= elf > a fair, hot wench in flame-colored taffeta, I see no reason why thou shou= ldst > be so superfluous to demand the time of the day. I wasted time and now d= oth > time waste me. > -- William Shakespeare > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040222105343.R29625>