Re: [asterisk-users] codec_g729a implicated in file descriptor buildup
On Wed, Dec 1, 2010 at 12:15 PM, Kevin P. Fleming kpflem...@digium.comwrote: 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. --snip-- 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-- Any estimates on how long it will take to seal the leak? Need a beta tester? murf Steve Murphy ParseTree Corp. 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] codec_g729a implicated in file descriptor buildup
On 12/03/2010 01:17 PM, Steve Murphy wrote: On Wed, Dec 1, 2010 at 12:15 PM, Kevin P. Fleming kpflem...@digium.com mailto:kpflem...@digium.com wrote: 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. --snip-- 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-- Any estimates on how long it will take to seal the leak? Need a beta tester? It will probably be scheduled to work on next week; it won't require beta testing, we've already found the problem in the source code and the fix is pretty simple. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] 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 0x1000 in ?? () #5 0x 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 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] codec_g729a implicated in file descriptor buildup
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 0x1000 in ?? () #5 0x 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: kflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
