From owner-freebsd-questions@FreeBSD.ORG Sun Feb 22 02:54:57 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7259116A4CE for ; Sun, 22 Feb 2004 02:54:57 -0800 (PST) Received: from mx1.mail.uk.clara.net (mx1.mail.uk.clara.net [195.8.69.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 285DB43D1D for ; Sun, 22 Feb 2004 02:54:57 -0800 (PST) (envelope-from david@carter-hitchin.clara.co.uk) Received: from du-041-0146.access.clara.net ([217.158.117.146] helo=stoat.clara.net) by mx1.mail.uk.clara.net with esmtp (Exim 4.24) id 1AurGB-000DP3-Am for freebsd-questions@freebsd.org; Sun, 22 Feb 2004 10:54:55 +0000 Received: from stoat.clara.net (localhost [127.0.0.1]) by stoat.clara.net (8.12.8p2/8.12.8) with ESMTP id i1MAugXN033345 for ; Sun, 22 Feb 2004 10:56:42 GMT (envelope-from david@carter-hitchin.clara.co.uk) Received: from localhost (david@localhost)i1MAuggs033342 for ; Sun, 22 Feb 2004 10:56:42 GMT (envelope-from david@carter-hitchin.clara.co.uk) X-Authentication-Warning: stoat.clara.net: david owned process doing -bs Date: Sun, 22 Feb 2004 10:56:42 +0000 (GMT) From: David Carter-Hitchin X-X-Sender: david@stoat.clara.net To: freebsd-questions@freebsd.org In-Reply-To: <20040221230536.GA38823@keyslapper.org> Message-ID: <20040222105343.R29625@stoat.clara.net> References: <20040221004102.M268@stoat.clara.net> <20040221230536.GA38823@keyslapper.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-RCPT: freebsd-questions X-Envelope-To: freebsd-questions@freebsd.org X-Clara-Scan: content scanned according to recipient preferences Subject: Re: C++ Memory Profiling/Debugging X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 10:54:57 -0000 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 > >