codec_g729a implicated in file descriptor buildup

Home » Asterisk Users » codec_g729a implicated in file descriptor buildup
Asterisk Users 2 Comments


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 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/
#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 (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?


2 thoughts on - codec_g729a implicated in file descriptor buildup

  • 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.