[asterisk-bugs] [JIRA] (ASTERISK-22945) [patch] Memory leak in chan_sip.c with realtime autoclear
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Mon Mar 10 09:31:06 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-22945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216272#comment-216272 ]
Matt Jordan commented on ASTERISK-22945:
----------------------------------------
That is probably a bad idea.
The bumping of the peer's ref count is done to ensure that the peer exists during the poke. By removing the ref bump, you're potentially creating a situation where a poke gets scheduled on a peer that may get destroyed before the scheduler fires.
While there may be a ref leak here - something needs to clear the ref bump at some point - simply removing the reference bump is most likely not the correct answer.
> [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)
More information about the asterisk-bugs
mailing list