[asterisk-dev] asterisk memory leaks

[Andre Courchesne - Prival]

Hi,

   Please take a look at bug 8660 (http://bugs.digium.com/view.php?id=8660). I 
had worked on providing info on this last year, but due to lack of time, never 
could complete the investigation. This bug includes method to reproduce and 
report memory usage by asterisk modules.

Andre Courchesne
Concepteur Logiciel - Software Developer acourchesne at prival.ca

PrivalODC Inc.
9955 ave Catania, local 145
Brossard, QC
J4Z 3V5

Web.: http://www.prival.ca
Tel.: (450) 761-9973 poste 635
        1-866-761-9973
Fax.: (450) 761-9842

Ce message e'lectronique ainsi que tous les documents annexe's s'adressent
exclusivement a` la personne ou a` l'entite' inscrit dans la rubrique
destinataire ; il peut contenir des renseignements de nature confidentielle
ou privile'gie'e  aux termes des lois applicables. Nulle autre personne ne
doit y avoir acce`s.  Si vous n'e^tes pas le destinataire convenu, nous vous
avisons par la pre'sente qu'il est strictement interdit d'en divulguer le
contenu, de le distribuer, le copier ou l' utiliser.  Veuillez aviser
l'expe'diteur imme'diatement par retour de courrier e'lectronique et supprimer
ce message de votre syste`me.  Toute diffusion ou reproduction de ce document
ainsi que tout mesure prise a` l'e'gard de la pre'sente est formellement
interdite.

Merci de penser a` l'environnement avant d'imprimer ce courriel.


Mark Spowage wrote:
> yes, i was considering that, and just wanted to see if others have the same
> evidence.
> 
> both sip and gtalk calls keep eating at the memory, all features such
> as call logging are
> disabled.
> 
> hopefully there will be enough space to run in the debug/developer mode.
> 
> 
> 
> On Tue, Nov 4, 2008 at 7:12 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> 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 Cohen
>> icq#16849755              jabber:tzafrir.cohen at xorcom.com
>> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
>> http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
> 
> 
> 
> --
> -----
> Fight back spam! Download the Blue Frog.
> http://www.bluesecurity.com/register/s?user=c3Bvd2FnZTI3NTk%3D
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev