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 >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
