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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/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:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-16 15:17 CDT
Last Modified:              2009-03-19 13:11 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
====================================================================== 

---------------------------------------------------------------------- 
 (0101984) svnbot (reporter) - 2009-03-19 13:11
 http://bugs.digium.com/view.php?id=14680#c101984 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 183246

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_queue.c

------------------------------------------------------------------------
r183246 | mmichelson | 2009-03-19 13:11:42 -0500 (Thu, 19 Mar 2009) | 22
lines

Merged revisions 183244 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

........
  r183244 | mmichelson | 2009-03-19 13:10:34 -0500 (Thu, 19 Mar 2009) | 16
lines
  
  Fix a memory leak associated with queues.
  
  For every attempt that app_queue made to place an outbound call to a
queue member,
  we would allocate a queue_end_bridge structure. When the bridge for the
call had
  completed, we would free the structure. Unfortunately not all call
attempts actually
  end up bridged to a member, so we need to be more selective of when to
allocate
  the structure. With this change, the allocation occurs in an area where
we can
  guarantee that the call will be bridged.
  
  (closes issue http://bugs.digium.com/view.php?id=14680)
  Reported by: caspy
  Patches:
        14680.patch uploaded by mmichelson (license 60)
  Tested by: caspy
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=183246 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-19 13:11 svnbot         Checkin                                      
2009-03-19 13:11 svnbot         Note Added: 0101984                          
======================================================================