[asterisk-bugs] [Asterisk 0010680]: memory leak due to ast_cdr_alloc invocations during call routing

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10680 
====================================================================== 
Reported By:                under
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10680
Category:                   Core-General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-10-2007 02:33 CDT
Last Modified:              09-10-2007 05:55 CDT
====================================================================== 
Summary:                    memory leak due to ast_cdr_alloc invocations during
call routing
Description: 
After approx. 600000 bridged calls asterisk grows up to 512Mb and OS
(Freebsd) forbids further memory allocations. Due to that asterisk process
dies.
Following scheme was used to produce the error situation:
1)sipp call originator(sipp -sn uac_pcap -p 5062 -s XXX 127.0.0.1).
2)sipp call terminator(sipp  -sn uas -p 5061)
3)asterisk config in 'additional information' section.
After problem detection asterisk was built with MALLOC_DEBUG. Further
investigation showed increasing memory allocations in cdr.c(ast_cdr_alloc).
After that following lines have been inserted in cdr.c:

--- cdr.c.orig  Mon Sep 10 10:47:05 2007
+++ cdr.c       Mon Sep 10 10:27:22 2007
@@ -437,6 +437,7 @@
 
                ast_cdr_free_vars(cdr, 0);
                free(cdr);
+               ast_log(LOG_NOTICE, "Freed cdr %i\n", cdr);
                cdr = next;
        }
 }
@@ -456,6 +457,7 @@
 struct ast_cdr *ast_cdr_alloc(void)
 {
        struct ast_cdr *x = ast_calloc(1, sizeof(struct ast_cdr));
+       ast_log(LOG_NOTICE, "Allocated cdr %i\n", x);
        if (!x)
                ast_log(LOG_ERROR,"Allocation Failure for a CDR!\n");
        return x;

After that in asterisk log whole call bridging look like this:

[Sep 10 10:31:05] NOTICE[30228]: cdr.c:460 ast_cdr_alloc: Allocated cdr
135926784
    -- Executing [380972400426 at customer:1] Dial("SIP/5063-081ac000",
"SIP/sipp-server/380972400426") in new stack
[Sep 10 10:31:05] NOTICE[30228]: cdr.c:460 ast_cdr_alloc: Allocated cdr
136064000
    -- Called sipp-server/380972400426
    -- SIP/sipp-server-081c7000 is ringing
    -- SIP/sipp-server-081c7000 answered SIP/5063-081ac000
    -- Native bridging SIP/5063-081ac000 and SIP/sipp-server-081c7000
[Sep 10 10:31:06] WARNING[30228]: channel.c:2605 ast_indicate_data: Unable
to handle indication 3 for 'SIP/5063-081ac000'
    -- Native bridging SIP/5063-081ac000 and SIP/sipp-server-081c7000
[Sep 10 10:31:06] NOTICE[30228]: cdr.c:460 ast_cdr_alloc: Allocated cdr
136054784
  == Spawn extension (customer, 380972400426, 1) exited non-zero on
'SIP/5063-081ac000'
[Sep 10 10:31:06] NOTICE[30228]: cdr.c:440 ast_cdr_free: Freed cdr
136054784

3 memory allocations with 1 memory releasing obviously leeds to memory
leak.

====================================================================== 

---------------------------------------------------------------------- 
 under - 09-10-07 05:55  
---------------------------------------------------------------------- 
corruptor, thank you very much.
Problem really resolved.
I never thought it is related to res_features.c... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-10-07 05:55  under          Note Added: 0070246                          
======================================================================