[asterisk-bugs] [Asterisk 0018924]: [patch] uncached realtime peers are put in peers_by_ip => memory leak

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18924 
====================================================================== 
Reported By:                wdoekes
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   18924
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Target Version:             1.4/1.6.2 Issues (Final Release)
Asterisk Version:           SVN 
JIRA:                       SWP-3221 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-03-04 01:53 CST
Last Modified:              2011-04-25 14:00 CDT
====================================================================== 
Summary:                    [patch] uncached realtime peers are put in
peers_by_ip => memory leak
Description: 
Hi,

I was having problems with UDP leaks at first. This was kindly fixed by
rgagnon with his patch in https://issues.asterisk.org/view.php?id=17255. After
applying that fix, I noticed that
memory usage was *still* increasing.

I've managed to trace the problem to the following:

Peers are put in the peers_by_ip list in parse_register_contact. However,
only if the peer is static or cached(-realtime), does it get a scheduled
expire_register() call. The expire_register makes sure the peer gets
removed from the global 'peers' and 'peers_by_ip' list.

These uncached realtime peers should not be in any of those lists, but
they are in the peers_by_ip list. (Which was hard to see, because the sip
show objects only shows the 'peers' container.)

Furthermore, when asterisk is stopped with 'core stop gracefully', these
peers from these two containers are properly unreferenced: the refcount
utility shows no problem.

But, in the mean time, asterisk has been eating away memory because it
keeps on adding peers to the peers_by_ip list which are never removed.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0017255 [patch] UDP ports not freed/ports leaking
child of            0018027 memory leak in chan_sip.c
====================================================================== 

---------------------------------------------------------------------- 
 (0134081) svnbot (reporter) - 2011-04-25 14:00
 https://issues.asterisk.org/view.php?id=18924#c134081 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 315212

U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r315212 | russell | 2011-04-25 14:00:25 -0500 (Mon, 25 Apr 2011) | 7 lines

Don't link non-cached realtime peers into the peers_by_ip container.

(closes issue https://issues.asterisk.org/view.php?id=18924)
Reported by: wdoekes
Patches:
      issue18924_uncached_realtime_peers_leak-1.6.2.17.patch uploaded by
wdoekes (license 717)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=315212 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-25 14:00 svnbot         Checkin                                      
2011-04-25 14:00 svnbot         Note Added: 0134081                          
======================================================================