[asterisk-dev] asterisk memory leaks

[Steve Murphy]

On Tue, 2008-11-04 at 15:12 +0200, Tzafrir Cohen wrote:
> On Tue, Nov 04, 2008 at 06:04:49AM -0600, Mark Spowage wrote:
> > with the latest 1.6 code,  asterisk looses memory , when it takes a
> > call to provide music on hold, via sip
> > 
> >               total         used         free       shared      buffers
> >  Mem:        62492        54064         8428            0         8656
> >  Swap:            0            0            0
> > Total:        62492        54064         8428
> > # free
> >               total         used         free       shared      buffers
> >   Mem:        62492        54068         8424            0         8656
> >  Swap:            0            0            0
> > Total:        62492        54068         8424
> 
> Those numbers are practically meaningless. It could be any other
> process.
> 
> The difference here is just 4 kb. Just an extra allocation of a page.
> This could be from one random call. One extra process. 
> 
> To get more useful data:
> 
> 1. Sample the data more often. e.g.: once an hour, with a script.
> 
> 2. Build Asterisk with memory allocaiton debugging (requires enabling
> dev mode, and has an overhead). This will allow you to see which part in
> Asterisk (and even: which exact call of malloc) is respossible for the
> constantly-increasing memory.

Tzafrir is totally correct. If you suspect that Asterisk is leaking
memory,
use the 'make menuselect' mechanism to set MALLOC_DEBUG in the
compiler flags category. make; make install; In the asterisk CLI,
when things are quiescent, do a 'memory show allocations f1'; this will
collect the results into file 'f1' then run a lot of calls or whatever; 
then enter 'memory show allocations f2' which collects the results 
into file 'f2'; If you sort the two files against file/function names,
and diff them, the leak will stand out.

Keep in mind, that Asterisk builds lists and caches in memory; that its
size will grow with the number of calls processed, but it should reach
an equilibrium point at a certain call volume and hover there. If you
find
that it grows with time, you should definitely follow the above
procedure
and report the problem.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20081104/d876692a/attachment.bin