[asterisk-bugs] [Asterisk 0013235]: Memory leak in Asterisk 1.4 and Trunk

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13235 
====================================================================== 
Reported By:                falves11
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13235
Category:                   Core/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 13058 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-08-04 18:31 CDT
Last Modified:              2008-09-08 10:45 CDT
====================================================================== 
Summary:                    Memory leak in Asterisk 1.4 and Trunk
Description: 
Both versions of Asterisk have a huge memory leak. I thought that it was
Trunk only and ported my app to 1.4. After 1 day and 17 hours the memory
has gone up 1.2 GB. I only have 300 open calls. My machine is open for
inspection. I am not using "malloc debug" and "don't optimize", for
performance reasons,but I will restart tonight the server. if somebody
wants to suggest any diagnostic technique, please let me know before I
restart.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013409 [patch] Huge memory leak because memory...
====================================================================== 

---------------------------------------------------------------------- 
 (0092173) murf (administrator) - 2008-09-08 10:45
 http://bugs.digium.com/view.php?id=13235#c92173 
---------------------------------------------------------------------- 
I think we found the problem. I just logged into the production server,
and asterisk has been up for 1 day 18 hours, and was at 245 Meg of virtual
memory.
It was handling around 60 sip channels.

A few minutes later, it had risen in memory, but a quick check showed that
it
was handling 80 sip channels. None were in Rx: BYE state; the list of
channels
looked as expected.

What was the problem? A large number of channels were dead, reporting Rx:
BYE
in a "sip show channels". All "dead" channels were to one certain vendor.
Doing
a "sip debug" revealed that after asterisk sent an INVITE to that vendor,
the
vendor responded with 100 Trying message, then a BYE, to which asterisk
would send an ACK, and the channel would be left in a limbo state.

What was happening was, the channel had some packets attached, and
therefore,
the driver would re-schedule the destruction, expecting the packets to be
removed in the normal course of events. But the packets were NOT removed,
and the rescheduling would occur over and over again ad infinitum, and the

channel would never get freed.

Josh Colp came up with the fix, which he attached above, but the patch, in

that format, did not solve the problem. The current invite state was not
PROCEEDING, but rather either TERMINATED or CONFIRMED. Once we knew this,
Josh suggested we make the call to __sip_pretend_ack(p) unconditionally,
and indeed, this works.

So, I committed this fix via:

1.4:        v. 141565
trunk:      v. 141566
1.6.0:      v. 141567
1.6.1:      v. 141572

We've waited till today, just to be sure that 
the asterisk reaches equilibrium state. It so appears.
If problems remain, tho, feel free to reopen this issue. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-08 10:45 murf           Note Added: 0092173                          
======================================================================