[asterisk-bugs] [JIRA] (ASTERISK-24307) Unintentional memory retention in chan_sip on sip reload

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-24307:
------------------------------------

    Severity: Critical  (was: Major)

> Unintentional memory retention in chan_sip on sip reload
> --------------------------------------------------------
>
>                 Key: ASTERISK-24307
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24307
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.12.0
>            Reporter: Etienne Lessard
>            Assignee: Rusty Newton
>            Severity: Critical
>         Attachments: sip.conf
>
>
> I could also have called this ticket "memory leak in chan_sip on sip reload", but since this not the typical memory leak where the reference to the memory is defintely lost, I used another name. Anyway.
> Here's how I'm reproducing it:
> {noformat}
> Given I have a Debian wheezy i686 with asterisk 11.12.0 
> Given I have a modules.conf with only permits loading of chan_sip.so (optional)
> Given I have a sip.conf with 500 peers
> Then the output of "ps -p $(pidof asterisk) --no-headers -o rss,vsz" is:
>    21072  30616
> After 100 "sip reload", it is:
>    25056  34676
> After 500 "sip reload", it is:
>    39700  50656
> After 1000 "sip reload", it is:
>    73728 110704
> After a "module unload chan_sip.so", it is:
>    20952  29716
> {noformat}
> Note that there's nothing else going on on the asterisk process -- no AMI connection, no SIP packet received, etc.
> I've taken a look at the code and done some testing, and the problem comes from how chan_sip manipulates the string fields in the sip_peer structure during a reload for a peer that hasn't changed. In the build_peer function, it first tries to reset these values to their default by calling the "set_peer_defaults" function, and then sets the new values. The current implementation of string fields doesn't handle well that scenario and this is leading to an unintentional memory retention, i.e. the string fields pool for each peer keeps growing on each sip reload.
> One naive way to "fix" this problem would be to call "ast_string_field_init(peer, 512)" just before calling set_peer_defaults, but this clears all string fields, which is probably not something we want to do since they are not all repopulated on sip reload, like for example, the "useragent" or "fullcontact" field.
> I found this problem while looking for a suspected memory leak we were observing on a production asterisk server.  The (generated) sip.conf on this server has a lot of peers, and most of the time only one peer gets added/modified/deleted for each sip reload done.  The sip reload operation happens quite frequently, i.e. more than 250 times per week. After a few weeks of uptime, there's a noticeable increase in the memory used by the process.



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