On Wed, Aug 31, 2005 at 09:30:31AM +0200, Alexandre CHARTRE - Solaris Sustaining wrote: > > If you have dbx(1), you can use the Run Time Checking (RTC) feature: > > - start dbx: % dbx /your/program > - turn on RTC leak checking: dbx> check -leaks > - start the program: dbx> run > - dbx will report memory leaks at the end of the execution of the program, > or you can suspend the execution (^C under dbx) and use the > 'showleaks' command to report memory leaks > > See 'help rtc' and 'help showleaks' under dbx for more details.
I did a bit of testing, and as far as I can tell, dbx(1)'s RTC does not detect or report mmap(2) leaks, so this won't help; he needs to use dtrace (or something) to match up mmap(2) results with stack traces, then use ::findleaks to find out what segments are leaked. Cheers, - jonathan > > Jonathan Adams wrote: > >On Tue, Aug 30, 2005 at 05:40:30PM -0700, prasad wrote: > > > >>On my Solaris 10 FCS, I backed out 117461-04 for now and ::findleaks > >>works: > >> > >>> ::findleaks > >>BYTES LEAKED VMEM_SEG CALLER > >>4194304 5 fd800000 MMAP > >>131072 1 fe4d0000 MMAP > >>262144 1 fe480000 MMAP > >>524288 1 fe380000 MMAP > >>1048576 1 fe200000 MMAP > >> > >>------------------------------------------------------------------------ > >> Total 5 oversized leaks, 6160384 bytes > > > > > >Those are leaked mmap(2) segments. Without using something like dtrace(1M) > >to track them, there's no good way to know how they are being allocated, > >since there's no userland information. > > > >Cheers, > >- jonathan > > > _______________________________________________ > mdb-discuss mailing list > mdb-discuss at opensolaris.org -- Jonathan Adams, Solaris Kernel Development
