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

[Asterisk Bug Tracker]

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 14:54 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0092276) murf (administrator) - 2008-09-09 14:54
 http://bugs.digium.com/view.php?id=13409#c92276 
---------------------------------------------------------------------- 
OK, I've just tried to confirm this the reason for falves's leakage, but I
cannot.
If I say "sip show channels" and take the output and put it in a file, and
then wait 20 minutes or so, and do it again, I cannot find any common
channels.

You try this; first, say "sip history"; then "sip show channels", and
collect the output, and copy it into a file. Wait 20 minutes and do the
"sip show channels" again. Copy and paste into a different file.

use 'sort' to merge and sort the files by the the Call-ID column. Look
for
two rows that have the same Call-ID column; I did this by using an editor
to 
move the callid field to the front of each line. Then I don't have to play
with the -k option in sort.

If you find a pair, then "sip show history xxxx with the callid; it will
do command completion for you if you hit tab.

Show us the history for that channel. Falves11's machine has been running
2 days, and I didn't see one channel that survived after 20 minutes. (he
has live traffic running). So, in his case, this is not the leak. But it
might be yours, so please, verify; jcolp couldn't make sense of your trace.
He wants to see the sip history of the channel. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-09 14:54 murf           Note Added: 0092276                          
======================================================================