Hi, Is it possible to use dtrace to find memory leak? If it is possible, then How? THX -- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
A few options... (assuming you''re talking about a userland process) * You can use the PID provider to probe on entry to malloc, and aggregate the malloc sizes - which should give you a clue as to where most of your mallocs come from. * You could also store the size of the allocated block in an associative array (in the pidXXX::malloc:return probe) and aggregate again on the block size on entry to free. This again will give you some clue of the size of blocks which are getting allocated and not freed, and you should be able to refine this down into giving you the stack on entry to malloc. * For a process which keeps growing and growing, I''ve had a bit of success just dumping out the stack on entry to brk(2). Of course, what I''d _really_ like to be able to do is to store the userland stack, indexed by the returned block address, and unset that element of the array on entry to free - then iterate that array to print it out. I can''t _quite_ do this with either an aggregation _or_ an associative array. I keep meaning to have a go at writing a DTrace consumer which should be able to do this, though. Alternatively, you might just find it easier to use libumem or dbx... -- Philip Beevers Fidessa Infrastructure Development mailto:philip.beevers at fidessa.com phone: +44 1483 206571> -----Original Message----- > From: dtrace-discuss-bounces at opensolaris.org > [mailto:dtrace-discuss-bounces at opensolaris.org]On Behalf Of CHIAN-PHON > LIN > Sent: 07 November 2005 21:27 > To: dtrace-discuss at opensolaris.org > Subject: [dtrace-discuss] Find memory leak using Dtrace > > > Hi, > > Is it possible to use dtrace to find memory leak? > If it is possible, then How? > > THX > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >****************************************************************** This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of royalblue. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. ******************************************************************
Philip, I am talking about userland. I appreciate your informations and certainly like to give them a try. THX. Philip Beevers wrote On 11/07/05 13:38,:> A few options... (assuming you''re talking about a userland process) > > * You can use the PID provider to probe on entry to malloc, and aggregate > the malloc sizes - which should give you a clue as to where most of your > mallocs come from. > * You could also store the size of the allocated block in an associative > array (in the pidXXX::malloc:return probe) and aggregate again on the block > size on entry to free. This again will give you some clue of the size of > blocks which are getting allocated and not freed, and you should be able to > refine this down into giving you the stack on entry to malloc. > * For a process which keeps growing and growing, I''ve had a bit of success > just dumping out the stack on entry to brk(2). > > Of course, what I''d _really_ like to be able to do is to store the userland > stack, indexed by the returned block address, and unset that element of the > array on entry to free - then iterate that array to print it out. I can''t > _quite_ do this with either an aggregation _or_ an associative array. I keep > meaning to have a go at writing a DTrace consumer which should be able to do > this, though. > > Alternatively, you might just find it easier to use libumem or dbx... >-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
I''d recommend libumem for tracking down the leak. mdb has the very handy "::findleaks" and various "::umem*" or "::uma*" dcmds for finding leaks and memory corruption (over runs, etc). On Nov 7, 2005, at 2:03 PM, CHIAN-PHON LIN wrote:> Philip, > > I am talking about userland. > I appreciate your informations and certainly like to give them > a try. > > THX. > > Philip Beevers wrote On 11/07/05 13:38,: > >> A few options... (assuming you''re talking about a userland process) >> >> * You can use the PID provider to probe on entry to malloc, and >> aggregate >> the malloc sizes - which should give you a clue as to where most >> of your >> mallocs come from. >> * You could also store the size of the allocated block in an >> associative >> array (in the pidXXX::malloc:return probe) and aggregate again on >> the block >> size on entry to free. This again will give you some clue of the >> size of >> blocks which are getting allocated and not freed, and you should >> be able to >> refine this down into giving you the stack on entry to malloc. >> * For a process which keeps growing and growing, I''ve had a bit of >> success >> just dumping out the stack on entry to brk(2). >> >> Of course, what I''d _really_ like to be able to do is to store the >> userland >> stack, indexed by the returned block address, and unset that >> element of the >> array on entry to free - then iterate that array to print it out. >> I can''t >> _quite_ do this with either an aggregation _or_ an associative >> array. I keep >> meaning to have a go at writing a DTrace consumer which should be >> able to do >> this, though. >> >> Alternatively, you might just find it easier to use libumem or dbx... >> >> > > -- > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
There is a nice article describing using dtrace to find memory leaks in C++ apps at http://developers.sun.com/solaris/articles/dtrace_cc.html. It could easily be modified to handle malloc/free. max On Mon, 2005-11-07 at 14:36, Chad Lewis wrote:> I''d recommend libumem for tracking down the leak. mdb has the very > handy "::findleaks" > and various "::umem*" or "::uma*" dcmds for finding leaks and memory > corruption (over runs, etc). > > > On Nov 7, 2005, at 2:03 PM, CHIAN-PHON LIN wrote: > > > Philip, > > > > I am talking about userland. > > I appreciate your informations and certainly like to give them > > a try. > > > > THX. > > > > Philip Beevers wrote On 11/07/05 13:38,: > > > >> A few options... (assuming you''re talking about a userland process) > >> > >> * You can use the PID provider to probe on entry to malloc, and > >> aggregate > >> the malloc sizes - which should give you a clue as to where most > >> of your > >> mallocs come from. > >> * You could also store the size of the allocated block in an > >> associative > >> array (in the pidXXX::malloc:return probe) and aggregate again on > >> the block > >> size on entry to free. This again will give you some clue of the > >> size of > >> blocks which are getting allocated and not freed, and you should > >> be able to > >> refine this down into giving you the stack on entry to malloc. > >> * For a process which keeps growing and growing, I''ve had a bit of > >> success > >> just dumping out the stack on entry to brk(2). > >> > >> Of course, what I''d _really_ like to be able to do is to store the > >> userland > >> stack, indexed by the returned block address, and unset that > >> element of the > >> array on entry to free - then iterate that array to print it out. > >> I can''t > >> _quite_ do this with either an aggregation _or_ an associative > >> array. I keep > >> meaning to have a go at writing a DTrace consumer which should be > >> able to do > >> this, though. > >> > >> Alternatively, you might just find it easier to use libumem or dbx... > >> > >> > > > > -- > > ************************************************ > > * C P Lin, Common Technology Project Lead. * > > * Sun Microsystems Inc. * > > * E-Mail: c.lin at sun.com * > > * Address: 4150 Network Circle, M/S UMPK12-330 * > > * Santa Clara, CA 95054 * > > * Phone: 650/352-4967 Fax: 650/786-7816 * > > ************************************************ > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Interesting, I also wrote some scripts about this topic it works well on normal situation, but if we call malloc very frequently(for example, more than 5000 times in 1second) the probes will definitely be droped even I raise the buffer to 1GB So we should find some better solution, I wonder if libumem is useful in this case. Lamb. Max Bruning wrote:>There is a nice article describing using dtrace to find >memory leaks in C++ apps at >http://developers.sun.com/solaris/articles/dtrace_cc.html. >It could easily be modified to handle malloc/free. > >max > >On Mon, 2005-11-07 at 14:36, Chad Lewis wrote: > > >>I''d recommend libumem for tracking down the leak. mdb has the very >>handy "::findleaks" >>and various "::umem*" or "::uma*" dcmds for finding leaks and memory >>corruption (over runs, etc). >> >> >>On Nov 7, 2005, at 2:03 PM, CHIAN-PHON LIN wrote: >> >> >> >>>Philip, >>> >>>I am talking about userland. >>>I appreciate your informations and certainly like to give them >>>a try. >>> >>>THX. >>> >>>Philip Beevers wrote On 11/07/05 13:38,: >>> >>> >>> >>>>A few options... (assuming you''re talking about a userland process) >>>> >>>>* You can use the PID provider to probe on entry to malloc, and >>>>aggregate >>>>the malloc sizes - which should give you a clue as to where most >>>>of your >>>>mallocs come from. >>>>* You could also store the size of the allocated block in an >>>>associative >>>>array (in the pidXXX::malloc:return probe) and aggregate again on >>>>the block >>>>size on entry to free. This again will give you some clue of the >>>>size of >>>>blocks which are getting allocated and not freed, and you should >>>>be able to >>>>refine this down into giving you the stack on entry to malloc. >>>>* For a process which keeps growing and growing, I''ve had a bit of >>>>success >>>>just dumping out the stack on entry to brk(2). >>>> >>>>Of course, what I''d _really_ like to be able to do is to store the >>>>userland >>>>stack, indexed by the returned block address, and unset that >>>>element of the >>>>array on entry to free - then iterate that array to print it out. >>>>I can''t >>>>_quite_ do this with either an aggregation _or_ an associative >>>>array. I keep >>>>meaning to have a go at writing a DTrace consumer which should be >>>>able to do >>>>this, though. >>>> >>>>Alternatively, you might just find it easier to use libumem or dbx... >>>> >>>> >>>> >>>> >>>-- >>>************************************************ >>>* C P Lin, Common Technology Project Lead. * >>>* Sun Microsystems Inc. * >>>* E-Mail: c.lin at sun.com * >>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>* Santa Clara, CA 95054 * >>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>************************************************ >>> >>>_______________________________________________ >>>dtrace-discuss mailing list >>>dtrace-discuss at opensolaris.org >>> >>> >>> >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> >> > >_______________________________________________ >dtrace-discuss mailing list >dtrace-discuss at opensolaris.org > >
It''s also possible to use the Sun Studio Performance Analyzer to look for leaks in user processes (collect -H on), or to use dbx to do runtime checking. Marty lambliu wrote On 11/07/05 16:56,:> Interesting, I also wrote some scripts about this topic > it works well on normal situation, > but if we call malloc very frequently(for example, more than 5000 times > in 1second) > the probes will definitely be droped even I raise the buffer to 1GB > So we should find some better solution, I wonder if libumem is useful > in this case. > > Lamb. > > Max Bruning wrote: > > >>There is a nice article describing using dtrace to find >>memory leaks in C++ apps at >>http://developers.sun.com/solaris/articles/dtrace_cc.html. >>It could easily be modified to handle malloc/free. >> >>max >> >>On Mon, 2005-11-07 at 14:36, Chad Lewis wrote: >> >> >> >>>I''d recommend libumem for tracking down the leak. mdb has the very >>>handy "::findleaks" >>>and various "::umem*" or "::uma*" dcmds for finding leaks and memory >>>corruption (over runs, etc). >>> >>> >>>On Nov 7, 2005, at 2:03 PM, CHIAN-PHON LIN wrote: >>> >>> >>> >>> >>>>Philip, >>>> >>>>I am talking about userland. >>>>I appreciate your informations and certainly like to give them >>>>a try. >>>> >>>>THX. >>>> >>>>Philip Beevers wrote On 11/07/05 13:38,: >>>> >>>> >>>> >>>> >>>>>A few options... (assuming you''re talking about a userland process) >>>>> >>>>>* You can use the PID provider to probe on entry to malloc, and >>>>>aggregate >>>>>the malloc sizes - which should give you a clue as to where most >>>>>of your >>>>>mallocs come from. >>>>>* You could also store the size of the allocated block in an >>>>>associative >>>>>array (in the pidXXX::malloc:return probe) and aggregate again on >>>>>the block >>>>>size on entry to free. This again will give you some clue of the >>>>>size of >>>>>blocks which are getting allocated and not freed, and you should >>>>>be able to >>>>>refine this down into giving you the stack on entry to malloc. >>>>>* For a process which keeps growing and growing, I''ve had a bit of >>>>>success >>>>>just dumping out the stack on entry to brk(2). >>>>> >>>>>Of course, what I''d _really_ like to be able to do is to store the >>>>>userland >>>>>stack, indexed by the returned block address, and unset that >>>>>element of the >>>>>array on entry to free - then iterate that array to print it out. >>>>>I can''t >>>>>_quite_ do this with either an aggregation _or_ an associative >>>>>array. I keep >>>>>meaning to have a go at writing a DTrace consumer which should be >>>>>able to do >>>>>this, though. >>>>> >>>>>Alternatively, you might just find it easier to use libumem or dbx... >>>>> >>>>> >>>>> >>>>> >>>> >>>>-- >>>>************************************************ >>>>* C P Lin, Common Technology Project Lead. * >>>>* Sun Microsystems Inc. * >>>>* E-Mail: c.lin at sun.com * >>>>* Address: 4150 Network Circle, M/S UMPK12-330 * >>>>* Santa Clara, CA 95054 * >>>>* Phone: 650/352-4967 Fax: 650/786-7816 * >>>>************************************************ >>>> >>>>_______________________________________________ >>>>dtrace-discuss mailing list >>>>dtrace-discuss at opensolaris.org >>>> >>>> >>>> >>> >>>_______________________________________________ >>>dtrace-discuss mailing list >>>dtrace-discuss at opensolaris.org >>> >>> >> >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> >> > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
CHIAN-PHON LIN wrote:>Hi, > >Is it possible to use dtrace to find memory leak? >If it is possible, then How? > >THX > >Hi Chian-Phon, http://blogs.sun.com/roller/page/sanjeevb?entry=dtrace_to_identify_memory_leaks Please check the above link. I have a D-script and a Perl script for the same. Hope this helps. Regards, Sanjeev.
Sanjeev, This is a wonderful piece of information and I definitely like to give it a try. THX. Sanjeev Bagewadi wrote On 11/08/05 20:44,:> CHIAN-PHON LIN wrote: > > >>Hi, >> >>Is it possible to use dtrace to find memory leak? >>If it is possible, then How? >> >>THX >> >> > > Hi Chian-Phon, > > http://blogs.sun.com/roller/page/sanjeevb?entry=dtrace_to_identify_memory_leaks > > Please check the above link. I have a D-script and a Perl script for the > same. > Hope this helps. > > Regards, > Sanjeev. > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Hi, I have asked same question some time ago... and somebody told me about this: use the right tool for the right job :) DTrace might be used as Sanjeev pointed out to detect memory leaks but libumem is just the right tool. Libumem does detect memory leaks and check the consistency of the heap. I think in this case is the right tool to use. hope it helps, Stefan This message posted from opensolaris.org