Summary:	ASTERISK-29878: chan_dahdi: memory leak in dahdi_restart
Reporter:	Frederic LE FOLL (flefoll)	Labels:
Date Opened:	2022-01-24 06:08:50.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_dahdi
Versions:	18.6.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Asterisk 18.6.0 Libpri 1.6.0 TE820 card	Attachments:	( 0) valgrind3-AMI-DAHDIRestart-x1000-asterisk-18.6.0-libpri-1.6.0.txt
Description:	Each call to dahdi_restart() increases asterisk RES memory usage in "top". Test under valgrind with one single PRI span configured. dahdi_restart() called N times (1000 for test), either through AMI DAHDIRestart, or through CLI "dahdi restart". Result shows as many "definitely lost" blocks as dahdi_restart() executions. It also shows two other memory leaks with fewer occurrences (approximately 25% and 70% respectively). Issue initially opened with "minor" severity because dahdi_restart() usually is not a frequent operation.
Comments:	By: Asterisk Team (asteriskteam) 2022-01-24 06:08:51.602-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Frederic LE FOLL (flefoll) 2022-01-24 06:11:21.452-0600 valgrind result after 1000 DAHDIRestart actions By: Frederic LE FOLL (flefoll) 2022-01-24 06:24:38.498-0600 Comments on valgrind3-AMI-DAHDIRestart-x1000-asterisk-18.6.0-libpri-1.6.0.txt: 1) valgrind execution shows that "main" memory leak" (occurs every time) is related to memory allocated by ast_cc_config_params_init() after chan_dahdi mkintf() function call, each time dahdi_restart() is executed. This memory leak can be fixed in dahdi_restart() before memset(), by adding a loop that : - checks cc_params fields in pris global array, - calls ast_cc_config_params_destroy() when not NULL, 2) Both other memory leaks come from memory blocks allocated by Libpri pri_new() function, called by sig_pri sig_pri_start_pri() function here also due to dahdi_restart() execution. - either allocated by pri_ctrl_new() (called by pri_new()) ; approx 25% occurrences, - or allocated by pri_schedule_grow() (pri_ctrl_new => q921_start() => q921_establish_data_link() => reschedule_t200() => pri_schedule_event => pri_schedule_grow) : approx 70% occurrences.