Summary:	ASTERISK-15392: memory leak in confic.c
Reporter:	Sascha Daniels (sdaniels)	Labels:
Date Opened:	2010-01-04 03:40:34.000-0600	Date Closed:	2010-01-04 14:04:22.000-0600
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/Configuration
Versions:		Frequency of Occurrence
Related Issues:
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.19.2 -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. ****** ADDITIONAL INFORMATION ****** 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 1.4.19.2 I tried all Versions from 1.4.19.2 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 https://issues.asterisk.org/view.php?id=14309 (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.