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. alex. 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 >
