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
#0 0x4d5544a0 in pipe () from /lib/libc.so.6
#1 0xb69384ce in __cxa_finalize () from
#2 0xae7fdae4 in ?? ()
#3 0xae7fcae4 in ?? ()
#4 0x00001000 in ?? ()
#5 0x00000000 in ?? ()
The version of the g279 module is: Digium G.729A Module Version
220.127.116.11_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
Anybody else see this?