Subject: Re: Memory leaks
From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Tue Jun 19 2001 - 22:56:03 CDT
Dom Lachowicz wrote:
>
> Mike suggests:
>
> > What we on the other hand would be able to do, is to use a specialized
> > heap,
> > telling it that "all allocations from this point is on the behalf of
> > xxyy"
> > and then when exiting telling it "xxyy is no more responsible for memory
> > allocations". Probably then by C++ RAII. At least it would remove all
> > those
> > bad "UT_String" messages, but tell us "class FooBar allocated 'n'
> > UT_strings
> > that it didn't release". Perhaps it could be useful?
> >
> > The somewhat troublesome part is that we possibly need a new heap
> > allocator.
> > Trust me (I've done it before) when I say that it's not something we
> > want to
> > do. Even that it would make debug-builds of AbiWord become self-checking
> > (in
> > debug-mode) it's not something we want to do.
> >
> > ... I think.
>
> FWIW, a company that I work for does something like this for its major
> product/library. It's quite useful to keep track of memory allocations, leaks
> (file and line number even), high-water marks, etc... and print those stats on
> termination. Is it worth our time and trouble to do this in Abi? I'm less
> convinced of that, but I'm open for suggestions.
Actually the last company I worked for did this too. In fact I was
the one who implemented it. Cross platform too for everything from
Palm Pilot to Unix. Of course we did it by #defining new, malloc(),
free(), etc to pass in __FILE__ and __LINE__ info. Which meant we
had to include our leak stuff in every single source file. It also
tracked mismatching new/new[],delete/delete[] etc. If we did choose
to do something like this as a build option, I wonder if we could
get some limited kind of stack trace into it...?
Andrew.
-- http://linguaphile.sourceforge.net _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b25 : Tue Jun 19 2001 - 22:54:07 CDT