[OPEN-ILS-DEV] valgrind finds memory leaks in libopensrf.so version 1.0.4

[Scott McKellar]

Thanks for the leak report.

There appear to be two distinct leaks here.  One of them I have found, 
and the other I haven't addressed yet.

The leak I found is at line 87 in osrfConfig.c.  We're pulling out a
piece from the middle of a jsonObject and leaking the surrounding husk.

If necessary, we can just clone the piece we want and then free the 
entire original.  I'm hoping to avoid that because of the overhead of
cloning.  I'll see if I can throw together a jsonObjectExtractIndex() function that we can use in this situation.  It will remove an entry
from a specified slot without destroying it.  Then we can destroy its
surroundings.

-------------

I have spent many hours hunting down memory leaks by staring at the 
code.  Obviously I missed at least a couple.

I should probably get in the habit of running valgrind from time to
time.  I installed it this afternoon and tried it out on something
I've been working on lately (a new JSON parser).  I'm happy to report
that valgrind had no complaints.

As valuable as valgrind is, it's no substitute for vigilance.  It can
only report on things that actually happen at runtime.  Many of the
leaks I have plugged in the past involved various error paths that would
be difficult or impossible to cover by testing.

Please let us know if you spot any other leaks.

Scott McKellar

--- On Fri, 3/27/09, Steven Chan <schan at vcn.bc.ca> wrote:

> From: Steven Chan <schan at vcn.bc.ca>
> Subject: [OPEN-ILS-DEV] valgrind finds memory leaks in libopensrf.so version 1.0.4
> To: open-ils-dev at list.georgialibraries.org
> Date: Friday, March 27, 2009, 6:34 PM
> When I run srfsh under the memory checker,
> 'valgrind', I find a number of memory leaks. Here
> are three scenarios:
> 
> 
> 1. Memory leak occurs after starting srfsh and then
> quitting.
> -------------------------------------------------------------

<snip -- messages from valgrind>

> Steven Chan
> Sitka project
> BC Evergreen