[OPEN-ILS-DEV] PATCH: osrf_system.c (memory leaks)

[Mike Rylander]

On Sun, Mar 16, 2008 at 12:22 PM, Scott McKellar <mck9 at swbell.net> wrote:
> This patch frees a couple of jsonObjects allocated by calls to
>  osrf_settings_host_value_object().

Applied.

>
>  With this post I complete my project of plugging memory leaks.  I
>  don't pretend to have plugged them all, but in systematically
>  searching for leaks I have traversed the tree as far as I intend to.
>
>  My search consisted of identifying functions that allocate memory, and
>  looking for a matching deallocation for every allocation (or multiple
>  deallocations when there are multiple code paths).  The approach does
>  not detect leaks that result from the overwriting of pointers without
>  first freeing the previous value of the pointer.  Detecting that kind
>  of leak would require that I trace the entire previous history of the
>  pointer, and I am not that ambitious.
>

Scott, this is truly amazing.

I know I speak for the entire Evergreen community when I say that we
simply can't thank you enough for all your hard work over the last
year (for those keeping score, GMail says we first heard from Scott on
Mon, Mar 19, 2007 at 10:43 PM Eastern).  I've been learning a lot
watching you work, and it's been personal pleasure.

Oh, and please don't stop!  (If you feel inclined to continue, of course. :) )

Thanks again,

--miker

>  There is also some code that I either didn't fix or didn't examine,
>  for various reasons:
>
>  1. Obsolescent code in osrf_legacy_json.c and the objson directory.
>
>  2. Calls to third party library functions that may allocate memory,
>  such as those used to parse XML.  Short of analyzing the third
>  party code I don't have a good way of identifying the right
>  functions.
>
>  3. Two files that appear to be experimental and/or unused:
>  osrf_transgroup.c and osrf_big_list.c.
>
>  4. osrf_chat_main.c.  It leaks memory, but the leaks occur just
>  before returning from main(), so fixing them wouldn't accomplish much.
>
>  5. basic_client.c, which doesn't compile and is probably obsolete.
>
>  Scott McKellar
>  http://home.swbell.net/mck9/ct/
>
>  Developer's Certificate of Origin 1.1 By making a contribution to
>  this project, I certify that:
>
>  (a) The contribution was created in whole or in part by me and I
>  have the right to submit it under the open source license indicated
>  in the file; or
>
>  (b) The contribution is based upon previous work that, to the best
>  of my knowledge, is covered under an appropriate open source license
>  and I have the right under that license to submit that work with
>  modifications, whether created in whole or in part by me, under the
>  same open source license (unless I am permitted to submit under a
>  different license), as indicated in the file; or
>
>  (c) The contribution was provided directly to me by some other person
>  who certified (a), (b) or (c) and I have not modified it; and
>
>  (d) In the case of each of (a), (b), or (c), I understand and agree
>  that this project and the contribution are public and that a record
>  of the contribution (including all personal information I submit
>  with it, including my sign-off) is maintained indefinitely and may
>  be redistributed consistent with this project or the open source
>  license indicated in the file.
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com