[asterisk-dev] Memory Leaks (A janitor project?)

[Steve Murphy]

In the course of investigating 13235, a 'huge' memory leak in 
Asterisk with odbc/tds in action, I am simply running Asterisk
under valgrind, and all I do is start up asterisk, let it load,
and then type in "stop gracefully", and I get a list of about 50 items.

(I'm using valgrind with asterisk 1.4, but trunk is similar!)

Now, these ~50 items that are 'leaked', are low priority, I realize.
Asterisk is in the middle of dying, and all its mem is about to get
absorbed back into the bit-bucket, I know. It's like rearranging the
deck chairs on the Titanic, making them look nice and neat, as it is
sinking. But, still, why do insist on getting rid of all warnings on
a compile? Cleaning up those 50 'leaks' shouldn't add a millisecond
to the stop time, and it will make searching for leaks a lot easier.

So, I obsessed last week, and fixed two or three leaks in 1.4,
which I haven't committed yet. Most are involved with 
data structures created during setup and load
processes, and simply forgotten at quit time. A few however, seem
by design. The structures set up by loading the crypto module 
have this:


static int unload_module(void)
{
/* Can't unload this once we're loaded */
return -1;
}

and so does the res_odbc:

static int unload_module(void)
{
/* Prohibit unloading */
return -1;
}

I considered having the quit handler set a global var
at quit time as it's going down, and override these
like this:

static int unload_module(void)
{
if (asterisk_is_quitting()) {
/* do cleanups */
return 0;
}


which would override the normal behavior at stop
time and clear out the leaks.


The biggest leak-on-stoppers are the module
loader, and the CLI stuff.

dlopen+dlclose: 12 reports
CLI: (el_initialize) 9 reports
res_odbc: 9 reports
ast_db: 4 reports
chan_sip: 3 reports
res_crypto: 2 reports

The remainder of the leaks are usually, but not
all at load time; some real-live leaks at runtime
are occurring in the logging system, and other
places, in hard-to-get-to places, but they don't pile 
up so fast when you do nothing but start up asterisk 
and then shut it down.

I don't have much time, as this is not real high-priority
stuff, but personally I think it'd be nice, to get rid of
some of these 'built-in' leaks, so they don't clutter up
up the valgrind results. For instance, we get a lot of 
dlopen reports because we, for the most part, don't unload
modules once they are loaded; the code to do it is there,
but not called, and it's all wrong and will have to be
refitted.

Wouldn't this make a nice janitorial project?

murf



-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080827/0647c223/attachment.bin