asterisk users - Dec 2010 - codec_g729a implicated in file descriptor buildup

Hello,

I wonder if anyone else has noticed this.

I see a pair of calls to pipe() within the codec_g729a, and suddenly, I have
a leaked file descriptor that remains until asterisk dies.

Now, maybe no-one sees this, mainly because I have no g729 licenses on the
machines where this happens. And conversely,
I haven't yet studied servers that do have licenses.  Why have
codec_g729a.so loaded if I don't have licenses? Well, I can
install licenses on the run as needed this way, and not worry about having
to install anything, or
muck things up if there is a mistake. I can mod the phones and get g729 used
without restarting asterisk
or loading modules.

On completely quiet machines, with no calls in or out,  I get one descriptor
per day, maybe of a daily reload or something. I
haven't gotten that far in my investigations yet.

Since the module isn't compiled with debug info, the best stack trace I can
get is:

#0  0x4d5544a0 in pipe () from /lib/libc.so.6
#1  0xb69384ce in __cxa_finalize () from
/usr/lib/asterisk/modules/codec_g729a.so
#2  0xae7fdae4 in ?? ()
#3  0xae7fcae4 in ?? ()
#4  0x00001000 in ?? ()
#5  0x00000000 in ?? ()

The version of the g279 module is:  Digium G.729A Module Version
1.6.2.0_3.1.4 (optimized for generic_32)

Just now, on a very low-volume asterisk server I am monitoring, two calls
just got processed.  The
g729a codec did a pair of pipe() calls, and voila! I have one more open file
descriptor as reported by lsof.

Some of my servers (which are busy, but nowhere near capacity!)  will build
up 100  such leaked descriptors per day, and unless I jack up the
maximum number of file descriptors, those servers will have to be restarted
about every 10 days, or they will eventually stop accepting
calls (or making them, for that matter). Not nice.

So, since there is no list of problems fixed with the current g729a module
distribution, (at least, no in the README in the dist,
is this a problem that is known? Is this a new problem? Should I call
support?

Anybody else see this?

murf
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20101201/2eddde8a/attachment.htm

On 12/01/2010 01:05 PM, Steve Murphy wrote:
> Hello,
>
> I wonder if anyone else has noticed this.
>
> I see a pair of calls to pipe() within the codec_g729a, and suddenly, I
> have a leaked file descriptor that remains until asterisk dies.
>
> Now, maybe no-one sees this, mainly because I have no g729 licenses on
> the machines where this happens. And conversely,
> I haven't yet studied servers that do have licenses.  Why have
> codec_g729a.so loaded if I don't have licenses? Well, I can
> install licenses on the run as needed this way, and not worry about
> having to install anything, or
> muck things up if there is a mistake. I can mod the phones and get g729
> used without restarting asterisk
> or loading modules.
>
> On completely quiet machines, with no calls in or out,  I get one
> descriptor per day, maybe of a daily reload or something. I
> haven't gotten that far in my investigations yet.
>
> Since the module isn't compiled with debug info, the best stack trace I
> can get is:
>
> #0  0x4d5544a0 in pipe () from /lib/libc.so.6
> #1  0xb69384ce in __cxa_finalize () from
> /usr/lib/asterisk/modules/codec_g729a.so
> #2  0xae7fdae4 in ?? ()
> #3  0xae7fcae4 in ?? ()
> #4  0x00001000 in ?? ()
> #5  0x00000000 in ?? ()
>
> The version of the g279 module is:  Digium G.729A Module Version
> 1.6.2.0_3.1.4 (optimized for generic_32)
>
> Just now, on a very low-volume asterisk server I am monitoring, two
> calls just got processed.  The
> g729a codec did a pair of pipe() calls, and voila! I have one more open
> file descriptor as reported by lsof.
>
> Some of my servers (which are busy, but nowhere near capacity!)  will
> build up 100  such leaked descriptors per day, and unless I jack up the
> maximum number of file descriptors, those servers will have to be
> restarted about every 10 days, or they will eventually stop accepting
> calls (or making them, for that matter). Not nice.
>
> So, since there is no list of problems fixed with the current g729a
> module distribution, (at least, no in the README in the dist,
> is this a problem that is known? Is this a new problem? Should I call
> support?
>
> Anybody else see this?
This problem may be in the license file checking code... I've just taken 
a quick look at it, and there may be at least one code path that leaks a 
pair of pipe file descriptors. I'll enter an internal issue to get this 
addressed ASAP. Thanks for the report.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org