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
====================================================================== 

---------------------------------------------------------------------- 
 (0130898) shaheryarkh (reporter) - 2011-01-22 21:07
 https://issues.asterisk.org/view.php?id=18027#c130898 
---------------------------------------------------------------------- 
I have a busy asterisk box with lots of realtime sip peers (3K+). This box
is now crashing almost daily due to this issue i guess, after processing
roughly 10K call.

I have attached bt-coredump.txt which shows back trace of Asterisk
generated core dump file (some information such as DNS name of server is
censored for security reasons).

One strange thing i found however is that this server also has a large
number (500+) of static sip peers with IP based provisioning, which are
there for emergency fail-over of another asterisk box. I see reference
count for these static peers are constantly increasing (25+ per peer)
though these peers can not send or receive anything to this asterisk box
since the other asterisk box is working fine. I wonder if this has anything
to do with bug.

On other hand, dynamic sip peers seem to have very normal reference count
(1-2 per peer).

These figures aren't effected whether or not i enable rtcachefriends flag
in sip.conf. SIP qualify is already disable for all peers (static or
dynamic).

I am running Asterisk 1.6.2.14 on CentOS 5.5 64-bit and obtaining
reference counts from 'sip show objects' command. Let me know if i can help
you guys further in solving this problem. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-22 21:07 shaheryarkh    Note Added: 0130898                          
======================================================================