Re: [Pdfedit-devel] Help me track down some memory leaks

[Michal H. <ms...@gm...>]

On Wed, Nov 28, 2007 at 10:48:17PM -0500, Gwurk wrote:
> Found it!
> 
> In CDict::_makeXpdfObject() and CArray::_makeXpdfObject(), you call
> _makeXpdfObject() to create the new Object to put into the
> dictionary/array. But if you look at Dict::add(char *key, Object
> *val), it makes ITS OWN COPY of the Object you give it:
>     *(entries[pos].val) = *val;
> Similarly, Array::add(Object *elem) also makes a COPY of the Object you give it:
>     elems[length] = *elem;
> 
> So the Object you created with _makeXpdfObject() is not used, and it
> never gets deleted.

yes exactly. We have to deallocate Object holder but keep its content
which is copied by value (there is no deep copy constructor).

> 
> How should we fix this?

Patch is in attachment. Thanks for reporting (this issue was introduced
by me in revision 1.10).

> 
> 
> On 11/28/07, Gwurk <gw...@fi...> wrote:
> > Hi,
> >
> > I'm using some memory-checking tools, and they indicate that there
> > might be some memory leaks in PDFedit (I'm using a pretty recent
> > version from CVS). I am trying to hunt down the leaks myself, but I
> > don't understand the code well enough yet. I was wondering if you
> > could take a quick look for me, and let me know if anything obvious
> > pops out at you:
> >
> > According to the memory-checking tools, one of the places that seems
> > to create objects without freeing them is the line:
> >                 dict->add(strdup((it->first).c_str()), prop->_makeXpdfObject());
> > in CDict::_makeXpdfObject() in cdict.cc. Can you take a quick look at
> > that, and tell me how the object made by prop->_makeXpdfObject() gets
> > freed?
> >
> > Thanks!
> >

Best regards
-- 
Michal Hocko