[asterisk-bugs] [JIRA] (ASTERISK-29071) memory leak in confbridge rises memory usage in frame.c linear per time

[Benjamin Keith Ford (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Keith Ford updated ASTERISK-29071:
-------------------------------------------

    Severity: Minor  (was: Major)

> memory leak in confbridge rises memory usage in frame.c linear per time
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-29071
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29071
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging
>    Affects Versions: 13.36.0, 16.13.0
>         Environment: Linux svast20 4.12.14-94.41-default #1 SMP Wed Oct 31 12:25:04 UTC 2018 (3090901) x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Stefan Ruf
>            Severity: Minor
>         Attachments: ami_commands.txt, confbridge.txt
>
>
> Using ConfbridgeMute / ConfbridgeUnMute over AMI and additionally MuteAudio on/off results in increasing values of frame.c - shown by "memory show summary". The values rises constant over time and channel. So a system with 24 GB RAM using 5 confbridges permanent with about 20 channels each ist filled up within a day and asterisk restarts.
> The problem ist reprorduceable and starts at a certain point. This point is action-id 1705904476_335#berta-ddab9ea6-dcb4-4e83-b9bf-ff5e44325110.
> At action-id 1705904476_336#berta-67e059f6-fa67-4d4a-a73a-d5fbd4cf6475 the value frame.c increases with double speed per time. Please see attached file <ami_commands.txt>. 
> Asterisk had been compiled with MALLOC_DEBUG and “cache_media_frames = no” in asterisk.conf
> For one channel the value increases about 32 per second; for two channels the value increases about 64 per second.
> Tested versions of asterisk are 16.13.0, 16.8-cert3, 13.36.0, 13.21-cert6, all of them with the described behaviour.



--
This message was sent by Atlassian JIRA
(v6.2#6252)