Subject: Re: Memory leaks
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Tue Jun 19 2001 - 22:33:00 CDT
Hi Mike, Paul,
> > Unfortunately, most of the items leaked weren't created directly via
> > malloc/new,
>
> That's not unfortunate, that's how OO works.
Yes. This also isn't a bad thing. We now have a single point of failure instead
of many potential ones, which is a good thing when it's in fact very managable.
> > 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.
I did the majority of this "grand-mal" rewrite, and yes, we need to look into
the memory leaks.
> >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.
Yes, it did. UT_String has been a wonderful addition to Abi.
> 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've done my best to get rid of the majority of UT_strdups in our code. FWIW,
UT_Strings are always created on the stack and not the heap (if this helps you
track down problems any).
> 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?
Purify, gprof, memprof, whatever you want to use. We need to kill these leaks
ASAP.
Dom
This archive was generated by hypermail 2b25 : Tue Jun 19 2001 - 22:33:18 CDT