[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=219395#comment-219395 ] 

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

Matt:
The first line is the problem. It isn't paired:

0x1b12bb8 +1   chan_sip.c:31137:build_peer (schedule qualify) [@1]

Yes, realtime is enabled and the memory leak is at peers autoclear and it isn't at registered peers. I use 2 asterisk systems with the same DB.

Is it clearer now ?

> [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-chan_sip-simplifies.patch, 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)