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

[Corey Farrell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222901#comment-222901 ] 

Corey Farrell commented on ASTERISK-24307:
------------------------------------------

I've only briefly looked into this issue, I do not believe {{chan_sip}} is the issue.  Comment before {{add_string_pool()}} in {{main/utils.c}}:
{code}
/*! \brief add a new block to the pool.
 * We can only allocate from the topmost pool, so the
 * fields in *mgr reflect the size of that only.
 */
{code}

I suspect this is the cause of continuous expansion of memory in use by stringfields, and in theory would effect all code that uses stringfields for data that changes.  I don't have time to work on this now, I hope to have a chance soon.

As a work-around, one thing that might help is to increase the size of the allocation used by chan_sip peer's.  For example if you increased from 512 to 1024 or 2048, that might make the first memory pool large enough to prevent needing to add more pools.  I'm unsure, if someone wanted to test this I'd be interested in the results.  It would either allow sip peers to stay within a single memory pool, or make the problem worse by allocating more memory per pool.

> 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
>            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)