Summary:	ASTERISK-22944: Reload Memory Leak.
Reporter:	Jean-Marc Pigeon (jmrcpn)	Labels:
Date Opened:	2013-12-05 20:32:11.000-0600	Date Closed:	2013-12-07 13:54:52.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	11.6.0	Frequency of Occurrence
Related Issues:
Environment:	CentOS release 6.4	Attachments:
Description:	System in production, work no trouble, found the used memory was a little bit high VSZ 203632, RSS 76152   Restarted asterisk (service asterisk restart) New Memory values are 81636 48376 (rather stable  while calls are processed). done an asterisk -rx "reload" New Memory values are 115128 82524 new asterisk reload New Memory values are 147112 115200 So it seems each time the SAME configuration is reloaded, used memory increase. test done on 2 different asterisks (but same asterisk versions).
Comments:	By: Matt Jordan (mjordan) 2013-12-06 11:42:31.501-0600 There is not enough information on this issue for someone to reproduce or diagnose this. You will need to determine where the leak is occurring and narrow down what component is in. Asterisk has a build option, MALLOC_DEBUG, that can be used to help determine if memory is being leaked. Enabling MALLOC_DEBUG and re-compiling Asterisk with said option will give you new CLI commands that can help show leaking memory. Alternatively, you can run Asterisk under valgrind. This will almost always show memory leaks. Instructions can be found on the [Asterisk wiki|https://wiki.asterisk.org/wiki/display/AST/Valgrind] for running Asterisk under valgrind. By: Jean-Marc Pigeon (jmrcpn) 2013-12-06 12:53:39.274-0600 Please would you mind to read my bug report carefully again, I am telling you everything. Problem is related to a configuration reload (SAME configuration reload again and again, make asterisk memory size as reported by Kernel to increase (around 30 Megs) every time). This means, you build the new configuration (allocating new Memory (malloc)), but are not fully freeing the old one (free)). Our production configuration files are not complex, sip.conf and extensions.conf (beside that, config files are genuine). Please NOTE: I am not reporting a potential memory leak while the system is doing  call tasks (I have no indication of malfunction in this area), just during the "asterisk -rx 'reload'" where you have a "jump" on memory reported by kernel. IMHO, problem is most probably in "dialplan reload". Hopefully, my report will make better sense now. By: Jean-Marc Pigeon (jmrcpn) 2013-12-06 17:52:58.408-0600 I do not fully confirm my finding. I do confirm after a restart, each reload increase memory used as displayed by kernel (ps axl), but it seems after few "reload", memory usage is reaching a "capped" value. So,  even if it is not perfect, it is not putting long term running asterisk in trouble. Sorry for the alarm. By: Matt Jordan (mjordan) 2013-12-07 13:54:33.507-0600 I'm going to go ahead and close out this issue as "Not a Bug". In the future, if you run into something like this, it is important to keep in mind that Asterisk does not have a single configuration repository. Each module - as well as files within the Asterisk core - are responsible for reading, parsing, and storing the configuration data provided by the Asterisk static conf files. Hundreds of such objects are created during a module load. Without knowing what modules you have loaded, which modules are being reloaded, and how the reload is being issued, you are asking the bug marshals to find a needle in a stack of needles, while telling them only that "there is a single needle that has a problem". :-) If you continue to have problems with module reloads, at a minimum, please isolate which module is causing the problem and attach the .conf file for the module that reproduces the issue.