[asterisk-bugs] [JIRA] (ASTERISK-22945) [patch] Memory leak in chan_sip.c with realtime autoclear

[ibercom (JIRA)]

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

ibercom commented on ASTERISK-22945:
------------------------------------

Asterisk is working fine for a week without problems. It has processed 16284 calls and it has between 180 and 200 peers.

The patch works, more or less. I don't see memory leaks in chan_sip.

Matt: In chan_sip code, the sip_poke_peer() function is called four times and all of them are different. Which is the correct form ?

I have reached my limit in chan_sip.c

> [patch] Memory leak in chan_sip.c with realtime autoclear
> ---------------------------------------------------------
>
>                 Key: ASTERISK-22945
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22945
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.6.0
>            Reporter: ibercom
>         Attachments: asterisk11.patch, cli-command.txt, memory-allocations.gz
>
>
> I have 2 servers with SIP realtime config and asterisk 1.8 and 11 each one.
> Server 1.8 have about 2000 register peers without obvious problems.
> Server 11 have about 20 register peers and chan_sip.c is constantly leaking memory with each call to the other peers.
> The SIP realtime config is the same:
> rtcachefriends=yes
> rtsavesysname=yes
> rtupdate=yes
> rtautoclear=yes		<< I think than here is the problem
> ignoreregexpire=yes
> When Server 11 look for some peer (not register peer) in sippeers table, it works with this info. Another (+1) static (realtime?) object. When the registration expires, memory leak. You can look for the same peer after some time and asterisk allocates memory again and it isn't freed.
> I have attached cli-command.txt which shows the asterisk's state with only 112 calls processed.



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