Subject: Re: Memory leaks
From: Mike Nordell (tamlin@algonet.se)
Date: Tue Jun 19 2001 - 18:53:11 CDT
Paul Rohr wrote:
> Martin,
>
> I'm afraid Andrew's right. In the past, I've spent a lot of time making
> sure that the Win32 debug memory heap showed *zero* leaks on a simple
> launch-and-exit scenario. I've just rebuilt a current view and now there
are
> a *ton* of small leaks in that scenario. Over a thousand, in fact. :-(
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.
> Unfortunately, most of the items leaked weren't created directly via
> malloc/new,
That's not unfortunate, that's how OO works.
> but were instead created via wrapper classes like UT_String,
> UT_StringBuf, and PP_PropertyType, which makes them much harder to track
> down and fix (unless your leak-detection tool captures full stack traces).
Which "Me and my Purify" did. :-P
> For example, at first glance, it looks like whoever did the tree-wide
grand
> mal rewrite to convert existing strings to UT_Strings may not have added
the
> necessary cleanup code in each instance to make sure that the UT_String
> destructor got called as needed.
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?).
> From examining the contents of the leaked
> items, it looks like all of the following portions of code need to be
checked:
>
> - preferences
> - custom dictionary entries
> - property names
> - style names
>
> And those are the easy ones. :-( Many of the other items leaked are
either
> empty or contain single characters and/or line noise, which means it'll be
a
> lot harder to track down the offending leaks.
Not at all, given the right tools! ;-)
What, you didn't like the invention:
char* p = new char[1]; // ?! ;-> (don't ask, I hope it's gone by now!)
> 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?
/Mike
This archive was generated by hypermail 2b25 : Tue Jun 19 2001 - 18:52:55 CDT