[asterisk-bugs] [Asterisk 0014680]: unfreed memory in try_calling

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14680 
====================================================================== 
Reported By:                caspy
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14680
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0.6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-16 15:17 CDT
Last Modified:              2009-06-11 09:40 CDT
====================================================================== 
Summary:                    unfreed memory in try_calling
Description: 
*CLI> core show uptime
System uptime: 2 days, 11 hours, 3 minutes, 56 seconds
Last reload: 2 days, 11 hours, 3 minutes, 56 seconds

*CLI> core show channels
Channel              Location             State   Application(Data)
0 active channels
0 active calls
44278 calls processed

*CLI> core show locks
[no lock at all]

*CLI> memory show summary astobj2.c
       420 bytes in 35 allocations in function 'ao2_link' of 'astobj2.c'
   5350600 bytes in 22225 allocations in function 'ao2_alloc' of
'astobj2.c'
5351020 bytes allocated in 22260 allocations

# rasterisk -x 'memory show allocations astobj2.c' | sort | uniq -c | sort
-rn
  22165        240 bytes allocated in            ao2_alloc at line   256
of astobj2.c
     44        508 bytes allocated in            ao2_alloc at line   256
of astobj2.c
     35         12 bytes allocated in             ao2_link at line   394
of astobj2.c
      5        548 bytes allocated in            ao2_alloc at line   256
of astobj2.c
      5        472 bytes allocated in            ao2_alloc at line   256
of astobj2.c
      2        676 bytes allocated in            ao2_alloc at line   256
of astobj2.c
      2        484 bytes allocated in            ao2_alloc at line   256
of astobj2.c
      1 5351020 bytes allocated in 22260 allocations
      1        968 bytes allocated in            ao2_alloc at line   256
of astobj2.c
      1        260 bytes allocated in            ao2_alloc at line   256
of astobj2.c


you can see here a 22165 allocations for 240 bytes, that was not released
(other are not so significant, but can be the same trouble).
and their count is constantly growing.

what else can i provide to find out a place of leak?

ps: valgrind is not an options, due to very huge slowdown. i've tried it.
:(
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014636 memory leak in "strings.c"
related to          0014260 Asterisk crashes anytime in call queues
====================================================================== 

---------------------------------------------------------------------- 
 (0106304) lmadsen (administrator) - 2009-06-11 09:40
 https://issues.asterisk.org/view.php?id=14680#c106304 
---------------------------------------------------------------------- 
That's because 1.6.0.10 is only a security update on top of 1.6.0.9. You
will have to wait for 1.6.0.11 for this to be in a release. Otherwise, find
this in the latest 1.6.0 SVN checkout. Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-11 09:40 lmadsen        Note Added: 0106304                          
======================================================================