[asterisk-bugs] [JIRA] (ASTERISK-29184) memory leak manager.c:purge_old_stuff not scheduled when manager.conf enabled=no

[Sean Bright (JIRA)]

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

Sean Bright updated ASTERISK-29184:
-----------------------------------

    Assignee: Diederik de Groot  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Are you running a patched version of Asterisk? I ask because, for example, the string {{SCCPDevice}} does not show up in the Asterisk 18 source code but it is in your event queue output.

> memory leak manager.c:purge_old_stuff not scheduled when manager.conf enabled=no
> --------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29184
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29184
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/ManagerInterface
>    Affects Versions: GIT, 17.8.1, 18.0.1, 16.15.0
>         Environment: Any
>            Reporter: Diederik de Groot
>            Assignee: Diederik de Groot
>              Labels: ami, core, manager, memory-leak
>         Attachments: eventq.log
>
>
> With enabled=off in manager.conf the `purge_old_stuff` function from main/manager.c is never scheduled and doesn't run. Meaning that any time the append_event is called (for example through __manager_event_sessions_va / manager_event) new memory is allocated for the event, it is inserted in the `eventqent`, but never released. Causing a non negligible memory consumption over time. Enabling manager/ami and reloading resolves the memory leak.
> Possible/Potential Solutions: 
> - append_event could bail out early and not allocate memory.
> - purge_old_stuff could be scheduled even if ami/manager is not enabled.
> - purge_old_stuff could be scheduled on some other monitoring thread.



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