Summary: | ASTERISK-27656: CDR: Leaking channel snapshots allocated by stasis_channel.c | ||
Reporter: | Kristijan Vrban (vrban) | Labels: | |
Date Opened: | 2018-02-05 07:53:29.000-0600 | Date Closed: | 2018-02-12 09:36:54.000-0600 |
Priority: | Major | Regression? | Yes |
Status: | Closed/Complete | Components: | CDR/General Resources/res_stasis |
Versions: | 13.19.0 15.2.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Debian 9 with asterisk-13.19.0 | Attachments: | ( 0) 27656-memory-show-allocations-after.txt.gz ( 1) 27656-memory-show-summary-after.txt ( 2) 27656-memory-show-summary-before.txt ( 3) valgrind.txt |
Description: | Seems there is a memory leak in "stasis_channels.c"
Command asterisk -rx'memory show summary' |sort -n show that 23443200 bytes in 15984 allocations in file stasis_channels.c is growing with every call. Minimal example config to reproduce: sip.conf {noformat} [general] bindaddr=192.168.198.133 [peer_in] type=peer insescure=port,invite port=5099 host=192.168.198.133 disallow=all allow=alaw allow=ulaw directmedia=no context=default {noformat} extensions.conf {noformat} [default] exten => 333,1,Dial(SIP/${EXTEN}@192.168.198.140) exten => 333,n,Hangup {noformat} and then sipp it, and check with command: asterisk -rx'memory show summary' |sort -n | ||
Comments: | By: Asterisk Team (asteriskteam) 2018-02-05 07:53:30.586-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. 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]. By: Kristijan Vrban (vrban) 2018-02-05 08:42:48.781-0600 Attached the valgrind.txt file based on: https://wiki.asterisk.org/wiki/display/AST/Valgrind By: Kristijan Vrban (vrban) 2018-02-07 03:21:02.944-0600 This issue does not occur with previous Asterisk-13.18.5. I see 13.19 has a lot of commits after 13.18. So one of this changes is the bad one. By: Alex Hermann (gaaf) 2018-02-09 10:07:19.669-0600 I see the same issue on a recent checkout of the 13 branch (42290f9a45). It seems related to CDRs. In my setup CDRs are stored via cdr_mysql in batch mode, no csv-file storage. All cdrs show up in the DB. No custom CDR variables are set in the dialplan. I'll attach the output of various "memory show" invocations. By: Alex Hermann (gaaf) 2018-02-09 10:10:39.045-0600 These files show memory summary before (clean start of Asterisk) and after 5000 calls. By: Alex Hermann (gaaf) 2018-02-09 11:13:25.510-0600 I reverted all commits one-by-one since 13.18 affecting the suspect files: {code} git log --oneline origin/13.18..origin/13 --no-merges -- main/cdr.c main/stasis.c main/stasis_channels.c {code} and arrived at the following commit as the culprit: {code} commit 85723a9e506bda9e21dbf3c06d93d961f10c6b75 Author: Richard Mudgett <rmudgett@digium.com> Date: Mon Oct 2 17:42:48 2017 -0500 cdr.c: Add container to key off of Party B channel names. {code} Unfortunately, this commit is not revertible by itself. To get a compilable Asterisk without this bug revert these commits: {code} 2b85799512 AST-2017-010: Fix cdr_object_update_party_b_userfield_cb() buf overrun 7f8c212e75 cdr.c: Rename the Party A CDR container. 85723a9e50 cdr.c: Add container to key off of Party B channel names. {code} Please mark this bug as a regression. By: Kristijan Vrban (vrban) 2018-02-12 04:14:44.850-0600 I just tested the fix from https://gerrit.asterisk.org/#/c/8175/ The issue seems to be solved with it. @Alex Hermann can you confirm that also on your setup? By: Alex Hermann (gaaf) 2018-02-12 07:21:12.778-0600 I'm unable to reproduce the issue with the fix from https://gerrit.asterisk.org/#/c/8175/ applied. Thanks [~rmudgett] for the quick fix. By: Friendly Automation (friendly-automation) 2018-02-12 09:36:55.241-0600 Change 8175 merged by Jenkins2: cdr.c: Fix runtime leak of CDR records. [https://gerrit.asterisk.org/8175|https://gerrit.asterisk.org/8175] By: Friendly Automation (friendly-automation) 2018-02-12 09:39:50.230-0600 Change 8176 merged by Jenkins2: cdr.c: Fix runtime leak of CDR records. [https://gerrit.asterisk.org/8176|https://gerrit.asterisk.org/8176] By: Friendly Automation (friendly-automation) 2018-02-12 16:05:11.290-0600 Change 8177 merged by Jenkins2: cdr.c: Fix runtime leak of CDR records. [https://gerrit.asterisk.org/8177|https://gerrit.asterisk.org/8177] By: Friendly Automation (friendly-automation) 2018-02-13 11:53:00.242-0600 Change 8198 merged by Jenkins2: cdr.c: Fix runtime leak of CDR records. [https://gerrit.asterisk.org/8198|https://gerrit.asterisk.org/8198] By: Friendly Automation (friendly-automation) 2018-02-13 11:58:56.935-0600 Change 8199 merged by Jenkins2: cdr.c: Fix runtime leak of CDR records. [https://gerrit.asterisk.org/8199|https://gerrit.asterisk.org/8199] |