[OpenSIPS-Users] troubleshooting memory problems

[Bogdan-Andrei Iancu]

Hi Richard,

What you found out is really true :) - you cannot make a comment in the 
middle of the list :)...

Anyhow, now that the mem debugger is compiled in, please let me know 
when you get the mem dumps to see where the leak is coming from.

Regards,
Bogdan

Richard Revels wrote:
> Just a quick follow-up on this.  I was cleaning up this server today (plus the couple problems I was having with b2bua - refer scenario were fixed with last bug fix) and realized that there are times when I can be pretty dense.
>
> I was somewhat perplexed as to why I didn't get the debug output I was looking for with only the DDBG_QM_MALLOC uncommented but Bogdan was pretty firm that should be all that is needed.  Commenting them back out today, it finally hit home it's a continued line and commenting out one line below another doesn't really do anything.  : >  Move DDBG_QM_MALLOC above DDBG_F_MALLOC in the file and THEN uncomment DDBG_QM_MALLOC.  
>
> Hopefully this will help someone down the road.  Should be obvious but got past me for quite a while.
>
> DOAH!
>
> Richard
>
>
> On May 27, 2010, at 10:35 AM, Bogdan-Andrei Iancu wrote:
>
>   
>> Hi Richard,
>>
>> Richard Revels wrote:
>>     
>>> In Makefile.defs uncomment
>>>
>>>         -DDBG_QM_MALLOC \
>>>         -DDBG_F_MALLOC \
>>>
>>>       
>> use only  DDBG_QM_MALLOC !!
>>     
>>> In script set 
>>>
>>> debug=6
>>> memlog=6
>>>
>>>
>>> Restart and let run for a while.  Then 
>>>
>>> cat /var/log/opensips-msg | egrep 'freeing|DBG:core:fm_malloc.*called' | sed -e 's/.*free.*\: \(.*\)/\1-mfree/' -e 's/.*malloc.*\: \(.*\)/\1-malloc/' | sort | uniq -c
>>>
>>> Adjust path for wherever you are logging of course.  Your output will have something like 
>>>
>>>   3015 parse_contact(81)-malloc
>>>   3015 parse_contact(81)-mfree
>>>   3015 parse_contacts(192)-malloc
>>>   3015 parse_contacts(192)-mfree
>>>  19592 parse_from_header(63)-malloc
>>>  19592 parse_from_header(63)-mfree
>>> 335368 parse_headers(309)-malloc
>>> 335368 parse_headers(309)-mfree
>>>
>>> for all the calls that are fine.  Then something like 
>>>
>>>  14922 do_parse_rr_body(65)-malloc
>>>   8989 do_parse_rr_body(65)-mfree
>>>
>>> or 
>>>
>>>   9016 sip_msg_cloner(437)-malloc
>>>   6003 sip_msg_cloner(437)-mfree
>>>
>>>       
>> That is not relevant as a mem block can be allocated in function X and 
>> freed in function Y, so you cannot correlate the numbers.
>>     
>>> for calls that need further looking into.  You'll probably want to go grep out the problem values in the log to get more information about what's calling them.
>>>
>>> I'm chasing a fairly nasty memory leak (shared memory) right now and thought I would document / share some of the methods we use for this type of thing.
>>>
>>>       
>> See:  http://www.opensips.org/Resources/DocsTsMem - try to get a dump to 
>> see if there are leaks.
>>
>> Regards,
>> Bogdan
>>     
>>> Richard
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>       
>> -- 
>> Bogdan-Andrei Iancu
>> www.voice-system.ro
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro