Summary:ASTERISK-15392: memory leak in confic.c
Reporter:Sascha Daniels (sdaniels)Labels:
Date Opened:2010-01-04 03:40:34.000-0600Date Closed:2010-01-04 14:04:22.000-0600
Versions:Frequency of
Environment:Attachments:( 0) valgrind.gz
Description:Asterisk is using more and more memory (up to 2GB), even when no calls are placed.

Versions: -1.4.22
1.4.28 not usable in my case.

After a few days Asterisk is using so much memory, that only a restart make it usable again, because it is getting dead slow and all RTP data, that passes asterisk is choppy.

After a restart astersik uses around 11MB. As soon as the first phones reregisters, memory usage is increasing. Reboot of all phones makes it even faster.

Memory is allocated by config.c in ast_variable_new at line 194

memory show allocations

45 bytes allocated in     ast_variable_new at line   194 of config.c

After a few hours I had 358194 of the above.

Running asterisk like that:

valgrind --leak-check=full --show-reachable=yes asterisk -cgv

used over 200MB of memory after around 4h and all together 4 calls!

stop gracefully did not work any more.


I am Using Gemeinschaft 2.3 (http://www.amooma.de/gemeinschaft) and 80 SIP Phones (most of them SNOM 3XX).

Default Version for Gemeinschaft would be

I tried all Versions from to 1.4.22.

Problem stays the same.

Tried 1.4.28

Cant use it because of known "Broken Pipe" problem in AMI
Comments:By: Leif Madsen (lmadsen) 2010-01-04 09:41:09.000-0600

Please provide the issue number that is preventing you from upgrading so we can link issues correctly.

By: Sascha Daniels (sdaniels) 2010-01-04 09:48:34.000-0600

I am talking about 0016229

I know that this was not a "real" issu, but I am having the same problem.

By: pkempgen (pkempgen) 2010-01-04 11:15:18.000-0600

One of the reasons that prevented the upgrade for some time is
(no need to link to it though) as well as one or two problems
with hint state changes being delayed in later versions.
Another reason is the renaming of Zaptel to Dahdi which will not
happen in Gemeinschaft 2.3.x just as it did not happen on Debian 5
"Lenny" (currently "stable").

By: Sascha Daniels (sdaniels) 2010-01-04 12:02:11.000-0600

Could just reproduce the problem on second server. With only 50 active phones memory usage stays at around 750MB and does not grow any more.

By: Tilghman Lesher (tilghman) 2010-01-04 12:46:52.000-0600

pkempgen: Am I understanding you correctly, then, that there are no open issues that would prevent the reporter from upgrading to the latest 1.4?

By: pkempgen (pkempgen) 2010-01-04 13:35:44.000-0600

> pkempgen: Am I understanding you correctly, then, that there are
> no open issues that would prevent the reporter from upgrading to
> the latest 1.4?

Frankly I don't know. I have more or less quit evaluating new
releases of Asterisk 1.4 more than a year ago because they did not
work for us for quite some time. Instead we're preparing for the
switch to Asterisk 1.6.x or 1.8 but that means more work than just
a matter of days.
In respect of Gemeinschaft I recommend against an upgrade to the
latest 1.4 because all kinds of nasty side effects might occur.
Don't know if the BLF problems are still present in the latest 1.4.
IMHO the reporter has a "legitimate interest" not to upgrade.

However I realize that this issue could be in a catch-22 situation
then. No idea how to move this forward.

By: Tilghman Lesher (tilghman) 2010-01-04 14:04:22.000-0600

sdaniels:  I'm afraid there's nothing we can do here.  You are, indeed, caught in a Catch-22 situation, where the frontend depends upon an older version and we at the backend need you to use the newest version.  Given the dependency, you need to resolve this with your packager, and if the packager has any remaining issues, he can resolve it with us.  Unless you're willing to go with a different frontend package, there's nothing more that we can do.