[OpenSIPS-Users] troubleshooting memory problems

[Richard Revels]

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