ASTERISK-13758: unfreed memory in try

[Home]

Summary: ASTERISK-13758: unfreed memory in try_calling

Reporter: caspy (caspy) Labels:

Date Opened: 2009-03-16 15:17:12 Date Closed: 2009-06-11 09:40:44

Priority: Major Regression? No

Status: Closed/Complete Components: Applications/app_queue

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) 14680.patch
( 1) 20090316__debug_bug14680.diff.txt

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. :(

Comments: By: Tilghman Lesher (tilghman) 2009-03-16 22:36:15

There is currently no good way in 1.6.0 to debug this, other than valgrind. Sorry.
By: Tilghman Lesher (tilghman) 2009-03-16 23:22:19

Try this patch. You're going to need to turn on MALLOC_DEBUG to turn on the full debugging, but it should stop showing astobj2.c as the source of the leak, and instead show where the real leak is located.
By: caspy (caspy) 2009-03-18 00:23:31

done. leak is here:
240 bytes allocated in try_calling at line 3354 of app_queue.c
By: Mark Michelson (mmichelson) 2009-03-18 13:20:52

I've uploaded 14680.patch for testing. Please let me know if it gets rid of the leak. Thanks!
By: caspy (caspy) 2009-03-19 12:56:54

With 14680.patch this leak has gone.
No more leaks in app_queue (in my case) observed. ;)

Thanks!
By: Digium Subversion (svnbot) 2009-03-19 13:10:35

Repository: asterisk
Revision: 183244

U trunk/apps/app_queue.c

------------------------------------------------------------------------
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 ASTERISK-13758)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy

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

http://svn.digium.com/view/asterisk?view=rev&revision=183244
By: Digium Subversion (svnbot) 2009-03-19 13:11:17

Repository: asterisk
Revision: 183245

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

------------------------------------------------------------------------
r183245 | mmichelson | 2009-03-19 13:11:16 -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 ASTERISK-13758)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=183245
By: Digium Subversion (svnbot) 2009-03-19 13:11:42

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 ASTERISK-13758)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=183246
By: Digium Subversion (svnbot) 2009-03-19 13:12:10

Repository: asterisk
Revision: 183247

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

------------------------------------------------------------------------
r183247 | mmichelson | 2009-03-19 13:12:10 -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 ASTERISK-13758)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=183247
By: caspy (caspy) 2009-06-11 08:50:58

Looking for my currently leaking 1.6.0.9 (and 1.6.0.10 too),
i see, that patch was lost somewere in the middle.

In comment 0101983 there is a log of commiting it to 1.6.0 branch, but 1.6.0.10 does not contain it now.
By: Leif Madsen (lmadsen) 2009-06-11 09:40:26

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!