Re: [Rlib-devel] Memory leaks

[Bob D. <bd...@si...>]

On Sat, 2005-06-04 at 02:31 -0600, William K. Volkman wrote:
> Hello,
> 	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?


> 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

Thanks for pointing these out.

Will you be able to send in a patch fixing all of this?

- Bob