[asterisk-bugs] [Asterisk 0013409]: [patch] Huge memory leak because memory of channel cdr struct is never returned

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Sep 9 12:08:01 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13409 
====================================================================== 
Reported By:                tomaso
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13409
Category:                   Core/Channels
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 137818 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-01 09:48 CDT
Last Modified:              2008-09-09 12:07 CDT
====================================================================== 
Summary:                    [patch] Huge memory leak because memory of channel
cdr struct is never returned
Description: 
After two days of stress testing by making lots of calls across sip and
dahdi channels the asterisk process memory reached dizzy values: VSZ=3,2GB,
RSS=1,6GB before asterisk stucked completely (even the RAM of our server
(2GB) is finite ;-) ).

Actually this problem is not a question of load, but appears for each
single call.

Using valgrind the reason for that was quickly found: The memory of the
channel cdr struct (chan->cdr) is never returned, not for sip, not for
dahdi channels, when a channel is cleared.

Reproduce:
a.f.a.p. default configuration (modules.conf, etc.)
Make lots of calls and see ps's VSZ and RSS values.

Interested in a patch ? Or is someone revise this anyway?

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013235 Memory leak in Asterisk 1.4 and Trunk
related to          0013444 After update from 140415 to 141991 get ...
====================================================================== 

---------------------------------------------------------------------- 
 (0092265) tomaso (reporter) - 2008-09-09 12:07
 http://bugs.digium.com/view.php?id=13409#c92265 
---------------------------------------------------------------------- 
murf-- 

For clarification the little memory leak I noticed was regarding SVN rev
141566 (the version before the second patch). 

With the SVN rev 141567 (with second patch) I've (almost) done what you
told me. Yes I have dead-channels, but they are all in Rx: INVITE state
(session timer off). The small resulting memory leak with this version
seems to be caused by the dead channels.

The sip channel seems to become dead after a session progress is sent to
the remote end. See attachment of one of these channels. Maybe the
SipP-client has lost its 'interest in this call'. Is the session timer
stopped totally after a session progress is sent? That would explain the
behaviour.

After a approx. 1 hour I've got 20 dead channels, 10 alive channels.
The memory used by asterisk changed from 10144 kb (idle) to 13232 (last
state)
If average memory use for a call is about 300kb (if this can be assumed at
all)this would be a fortification of 'memory leak only caused by the dead
channels'.

Is this enough information for you? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-09 12:07 tomaso         Note Added: 0092265                          
======================================================================




More information about the asterisk-bugs mailing list