Jonathan raises a good point, dbx/RTC just interpose malloc/free to find leaks, so it can't find mmap problems. I think purify uses the same mechanism so it will certaintly not find the problem either.
The libthread/libc uses mmap to allocate various object. As you noticed, in your case, pthread_mutexattr_init() is involved. So pthread_mutexattr_destroy() has to be invoked to release the mapping. The stack shows several constructors: ios, ostrstream and MasterIndexRecord; if the destructor MasterIndexRecord does destroy the ostrstream object then the problem is certaintly in libiostream. So I think you should first check that the destructor MasterIndexRecord does destroy the ostrstream object created in the constructor. If it does so, then you can try to write a small test-case which just create and destroy a ostrstream object and check if we have a leak in this case. alex. prasad wrote: >>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 >> > > > Let me ask a few stupid questions: > > * Will Purify catch these type of leaks? > * Here's a stack of backtraces using Brendan's dtruss: > ------------------------------------------------------------------------------------------------------------- > wembley-bash# ./dtruss -f -s -t mmap -p 23047 > PID/LWP SYSCALL(args) = return > 23047/6: mmap(0x10000, 0x80000, 0x7) = -33554432 0 > > libc.so.1`mmap+0xc > libc.so.1`pthread_mutexattr_init+0x4 > libiostream.so.1`__1cNstream_rmutexLrmutex_init6M_v_+0x24 > libiostream.so.1`__1cDios2t5B6M_v_+0x48 > libiostream.so.1`__1cKostrstream2t6Mpcii_v_+0x6c > libbfsDataPump.so`__1cRMasterIndexRecord2t5B6Mipc_v_+0xc0 > > dataPump.xxx`__1cWMasterIndexFileHandlerYgetNextMasterIndexRecord6MI_pnRMasterIndexRecord__+0x2a8 > > dataPump.xxx`__1cRMasterIndexReaderRrunThreadFunction6Mpv_1_+0x1b0 > libpthreadWrapper.so`0xfeee572c > libc.so.1`_lwp_start > > 23047/6: mmap(0x10000, 0x100000, 0x7) = -35127296 0 > > libc.so.1`mmap+0xc > libc.so.1`pthread_mutexattr_init+0x4 > libiostream.so.1`__1cNstream_rmutexLrmutex_init6M_v_+0x24 > libiostream.so.1`__1cDios2t5B6M_v_+0x48 > libiostream.so.1`__1cKostrstream2t6Mpcii_v_+0x6c > libbfsDataPump.so`__1cRMasterIndexRecord2t5B6Mipc_v_+0xc0 > > dataPump.xxx`__1cWMasterIndexFileHandlerYgetNextMasterIndexRecord6MI_pnRMasterIndexRecord__+0x2a8 > > dataPump.xxx`__1cRMasterIndexReaderRrunThreadFunction6Mpv_1_+0x1b0 > libpthreadWrapper.so`0xfeee572c > libc.so.1`_lwp_start > > 23047/6: mmap(0x10000, 0x200000, 0x7) = -37748736 0 > > libc.so.1`mmap+0xc > libc.so.1`pthread_mutexattr_init+0x4 > libiostream.so.1`__1cNstream_rmutexLrmutex_init6M_v_+0x24 > libiostream.so.1`__1cDios2t5B6M_v_+0x48 > libiostream.so.1`__1cKostrstream2t6Mpcii_v_+0x6c > libbfsDataPump.so`__1cRMasterIndexRecord2t5B6Mipc_v_+0xc0 > > dataPump.xxx`__1cWMasterIndexFileHandlerYgetNextMasterIndexRecord6MI_pnRMasterIndexRecord__+0x2a8 > > dataPump.xxx`__1cRMasterIndexReaderRrunThreadFunction6Mpv_1_+0x1b0 > libpthreadWrapper.so`0xfeee572c > libc.so.1`_lwp_start > > 23047/6: mmap(0x10000, 0x400000, 0x7) = -46137344 0 > > libc.so.1`mmap+0xc > libc.so.1`pthread_mutexattr_init+0x4 > libiostream.so.1`__1cNstream_rmutexLrmutex_init6M_v_+0x24 > libiostream.so.1`__1cDios2t5B6M_v_+0x48 > libiostream.so.1`__1cKostrstream2t6Mpcii_v_+0x6c > libbfsDataPump.so`__1cRMasterIndexRecord2t5B6Mipc_v_+0xc0 > > dataPump.xxx`__1cWMasterIndexFileHandlerYgetNextMasterIndexRecord6MI_pnRMasterIndexRecord__+0x2a8 > > dataPump.xxx`__1cRMasterIndexReaderRrunThreadFunction6Mpv_1_+0x1b0 > libpthreadWrapper.so`0xfeee572c > libc.so.1`_lwp_start > ------------------------------------------------------------------------------------------------------------------------------------------------- > > so, is libiostream causing those leaks? > > Thanks, > -- prasad > This message posted from opensolaris.org > _______________________________________________ > mdb-discuss mailing list > mdb-discuss at opensolaris.org
