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
