Subject: Re: Memory leaks
From: Paul Rohr (paul@abisource.com)
Date: Tue Jun 19 2001 - 20:49:42 CDT
At 01:53 AM 6/20/01 +0200, Mike Nordell wrote:
>I think this connects to my last Purify session (a month or so ago?). Either
>the Document isn't released, or it doesn't takes care of deleting all the
>Properties. That's what I believe it boils down to. Unfortunately I had only
>the time to report it, not fix it, and apparently no one else had the time
>to fix it either.
Sorry I missed your note on this subject. The document is definitely
getting released, and as of late January, the only leak in a launch-and-exit
scenario was the RemapGlyphs cache.
http://www.abisource.com/mailinglists/abiword-dev/01/February/1022.html
I'm glad to hear that Purify generates stack traces for each leak, because
my tool (the VC debug heap) doesn't. Could you do a run and identify which
of the new UT_String uses need to be cleaned up?
>> Unfortunately, most of the items leaked weren't created directly via
>> malloc/new,
>
>That's not unfortunate, that's how OO works.
Sure, that's how OO works, but when you're trying to plug leaks without a
Purify license, it most definitely *is* unfortunate. :-)
>From the top of my head I know that the Attributes _sometimes_ did UT_Strdup
>and sometimes did not. No logic in the discrepancies. I'd say this is #1 of
>these leaks. Adding UT_String perhaps helped focus on this problem, but it
>did also help to clean up the memory managing chores.
>
>I did fix the attr. problem locally (to _always_ dup. the string), but then
>I was told to hold since (I believe) Dom had some serious rewrite up the
>sleeve. I held, but I believe much of those UT_strdup might be left in the
>attr. class(es?).
I have no idea how the leaks got introduced. I just know they're new and
they need to be plugged. :-)
Once they're isolated, fixing them should be easy, no?
>> What leak detection tools are people using on other platforms to make sure
>> their code is leak-free?
>
>I use Purify on Win32 from time to time to have a look at the state of
>AbiWord. So far, during my year of on-and-off participation. it has
>increased the quality a _lot_ if my memory serves me. Perhaps I should have
>another run.
>
>Actually, coming to think of it, me (or anyone alse with access to it)
>running Purify on the code should probably be part of the release procedure!
>What do you think?
That'd be wonderful.
In fact, I'd go you one better. Insofar as there are tools to automatically
detect whether our code is both:
warning-free *and* leak-free
I'd strongly encourage *all* AbiWord developers to use such tools, if
available, before *every commit*, as a matter of professional pride. (For
example, all Win32 developers could get into the habit of doing debug runs
from the IDE to confirm that nothing got left on the debug heap.)
How does that sound? Could this be done on other platforms, too?
Paul
This archive was generated by hypermail 2b25 : Tue Jun 19 2001 - 20:42:21 CDT