>
> Jonathan raises a good point, dbx/RTC just
> st 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
> us 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,
> s, 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
> he 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.
>
>
Our use of ostrstream seems to be something similar to this bug 4285375:
void printPid()
{
ostrstream os;
os << getpid() <<ends;
cout << "pid is "<< os.str() <<endl;
//os.flush();
return;
}
main()
{
while(1)
printPid();
exit(0);
}
The above seems to break in Solaris 10 whereas it works in Solaris 8. Maybe
libiostream is broke in Solaris 10??
-- prasad
This message posted from opensolaris.org
