No subject

exhausted, and asterisk will be killed/restarted by the watchdog, which in
my case is snmpd.

Seems like most allocations are done around lines 23905 and 23908 in
build_peer() in chan_sip.c

Second file is provided in the zip archive, due to its extremely large
size.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018014 large memory consumption of udptl.c module
====================================================================== 

---------------------------------------------------------------------- 
 (0130479) drookie (reporter) - 2011-01-13 23:03
 https://issues.asterisk.org/view.php?id=18027#c130479 
---------------------------------------------------------------------- 
In my turn I did all that I promised and ran a couple of tests with sipp.
- sipp calling a static Answer()/Hangup extension (no leak here).
- sipp calling non registered realtime peer
- sipp calling registered realtime peer
- sipp calling registered realtime peer with another sipp instance
answering

Although I was capable to rise RSS from 50M to 320M, I didn't figure out
the exact sequence to recreate memory leaking. Because during the time from
50V to 320M asterisk had an RSS more than 320M and then it was able to drop
it down. So I'm  pretty much stuck here. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-13 23:03 drookie        Note Added: 0130479                          
======================================================================