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

[Scott McKellar]

--- Dan Scott <denials at gmail.com> wrote:

<snip>

> Hey Scott:
> I'm interested in your technique for spotting problems like memory
> leaks -
> are you simply reading the code to determine where problems are
> occurring,
> or are you putting some tools to work? There's not a lot of new C
> coding
> going on in Evergreen recently, but if we ramp up again it would be
> useful
> to adopt your tactics and hopefully avoid introducing new problems.
> 
> Dan

No special tools -- just grep, eyeballs, and taking notes.

Lately I've been concentrating on memory leaks, taking a very
systematic approach.  I started with a short list of functions that
return pointers to newly allocated memory -- malloc, calloc, strdup,
and realloc.  Then I grepped to find where these functions are 
called.  For each call, one of several possibilities occurs:

1. I find where the memory is freed, and go on to the next call.

2. The pointer is re-returned by function foo().  I add foo() to
the list and grep for the places that call it.

3. The memory is never freed, and we lose the pointer.  I find a
way to plug the leak.

4. The memory is never freed, but it's not really a leak, because
we store the pointer in a variable or struct with static storage
duration.  The memory remains allocated and accessible until the
program terminates.

4. The pointer is installed in a struct somewhere.  I make sure that 
the pointer is freed when the struct is deallocated (or, in some
cases, I verify that the struct is never deallocated, as in case 4.)

I maintain a list of memory-allocating functions and the source
files that invoke them.  The list grows and shrinks as I traverse
the tree, adding new functions to the list and scratching off old 
ones that I have resolved one way or another.

Whenever decide to update a file, I have an opportunity to apply 
the standard fetishes:

-- const-correctness
-- explicitly populating all members of newly allocated structs
-- turning globals into statics whenever possible
-- correcting the inappropriate use of reserved identifiers (mainly
   those with leading double underscores)
-- replacing deprecated identifiers with camel case

In the course of doing all this, I sometimes stumble on some other
opportunity, on an ad hoc basis.  If I don't feel like making the 
change right away, I add it to a list of things to return to some day.

Mostly I'm just staring at the code, but in run-time testing I have
often found it useful to do stupid things in the configuration files
or other inputs, in order to see what happens.  I won't claim that
this technique is always deliberate.

Scott McKellar
http://home.swbell.net/mck9/ct/