Re: [Rlib-devel] Memory leaks

[William K. V. <wk...@us...>]

Hello Bob,
On Sun, 2005-06-05 at 11:11, Bob Doan wrote:
> On Sat, 2005-06-04 at 02:31 -0600, William K. Volkman wrote:
> > 	While perusing the source code I noticed that the
> > usage of libxml2 xmlGetProp was incorrect, the result of the
> > call should be freed via xmlFree.  I've made numerous fixes
> > to parsexml.c and free.c to fix the oversight.  
> 
> Hymm.. your right.
> 
> Any chance you'll sign this http://rlib.sicompos.com/copyright_form.pdf
> and send in a patch?

Can do.

> 
> 
> > While testing
> > those changes however I noticed that memory appeared to
> > be leaking at a value equal to the size of the report.  After
> > much pondering and stepping through things with gdb I've
> > located the cause however fixing it is non-trivial (removing
> > the memory leak fixes for libxml2 usage might help).  What
> > is happening is this, if a part only has one report a call
> > is made to rlib_evaulate_single_report_variables, which
> > in turn calls rlib_resolve_report_fields.  Later in the
> > make_report routine a call is made to rlib_layout_part_tr
> > which again will trigger a call to rlib_resolve_report_fields.
> > Thus stepping on the results of the first call and leaking
> > about a reports worth of memory.  
> 
> 
> > I'm not certain on how
> > to proceed from here, perhaps coding an equivalent of
> > rlib_report_free that only destroys the "dynamically"
> > allocated portions of the report, or perhaps add look before
> > allocating to the rlib_resolve_report_fields routine.  Anyway
> > since "parts" are the newly implemented feature it would
> > probably be best for me to punt and let the designer think
> > about what the rlib_evaulate_single_report_variables routine
> > is to accomplish and how best to do so.  If someone would like
> > the patches I made to parsexml.c and free.c let me know.
> 
> To fix this double free probably in rlib_layout_part_tr check 
> "report->is_the_only_report" and don't call it again if it is TRUE

Well that seems to be an elegantly simple fix, I'll try it and let you
know.

> Thanks for pointing these out.
> 
> Will you be able to send in a patch fixing all of this?

I'll be happy to I normally use "diff -u" format, is that OK?

Cheers,
William.