Connecting Tech Pros Worldwide Forums | Help | Site Map

Strstreambuf memory leak

Rajwarya
Guest
 
Posts: n/a
#1: Jul 22 '05
Hi ppl,

I am trying to run a code on SUN OS 5.8 and using Sun WorkShop 6
update 2 C++ 5.3. The problem is that the code is leaking memory in
strstreambuf. We are using ostrstream with rdbuf()->freeze(0) but
still its bleading. I am pasting the purify output below. Please let
me know how to get rid of this.
Also we are using latest patch release for libCstd.so.1 i.e Sun C++
5.6 Patch 108434-17 DEV

MLK: 1430016 bytes leaked in 11172 blocks
This memory was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv___1 [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void*operator new[](unsigned) [rtlib.o]
int std::strstreambuf::overflow(int) [libCstd.so.1]
long std::strstreambuf::xsputn(const char*,long)
[libCstd.so.1]
Block of 128 bytes (11172 times); last block at 0x1675f1d8
MLK: 633700 bytes leaked in 7034 blocks
MLK: 20480 bytes leaked in 160 blocks
This memory was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv___1 [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void*operator new[](unsigned) [rtlib.o]
int std::strstreambuf::overflow(int) [libCstd.so.1]
void __rwstd::digit_writer<char,std::ostreambuf_iterato r<char,std::char_traits<char>[color=blue][color=green]
> >::put_digits(char) [libCstd.so.1][/color][/color]
Block of 128 bytes (160 times); last block at 0x1675f100


Thanks
Rajat

Ali Cehreli
Guest
 
Posts: n/a
#2: Jul 22 '05

re: Strstreambuf memory leak


On Fri, 16 Jul 2004 07:51:18 -0700, Rajwarya wrote:
[color=blue]
> I am trying to run a code on SUN OS 5.8 and using Sun WorkShop 6 update
> 2 C++ 5.3. The problem is that the code is leaking memory in
> strstreambuf. We are using ostrstream with rdbuf()->freeze(0) but still
> its bleading.[/color]

Have you also ensured that the call to freeze is always executed?
Could there be an exception thrown before getting to that line?

Ali
Ali Cehreli
Guest
 
Posts: n/a
#3: Jul 22 '05

re: Strstreambuf memory leak


On Fri, 16 Jul 2004 23:21:42 -0700, Rajwarya wrote:
[color=blue]
> No the line rdbuf->freeze(0) is getting excecuted.[/color]

I will be very picky here and say that you can't be sure that it's
called every time it is needed.

#include <strstream>

void bar()
{
/* ... */
}

int main()
{
ostrstream out;
out << 42;
out.str();
bar(); // If bar throws, the following line is not executed
out.freeze(false);

out.str(); // BUG: need to call freeze again; but forgot!
}

At a previous job, I caught more than 50 memory leaks related to the
use of ostrstream, just by grepping for 'ostrstream' and examining
code. Most of them were related to missing 'freeze' calls.

I replaced all of them with ostringstreams but then some operations
became very slow: 10 seconds instead of 1 second! :(

Also, I am not sure whether you are supposed to call freeze on rdbuf
or ostrstream.

If Purify's output is not helpful enough try other tools like the free
valgrind on Linux.

Ali
Martin Sebor
Guest
 
Posts: n/a
#4: Jul 22 '05

re: Strstreambuf memory leak


....[color=blue]
> But it still there are other
> leaks in strstreambuf to be plugged. Apart from ostrstream classes
> there are other classes also that are bleading I guess. Can you tell
> me those classes and how to seal them.[/color]

The C++ Standard Library implementation that SunPro uses by default caches
a bunch of data in locale, iostreams, and even some containers (e.g., list).
Unfortunately, the library never releases the caches which shows up as memory
leaks in Purify. Your best option is to complain to Sun and nag them to update
to a later version of the library. Or buy the latest version of the library
from Rogue Wave :) It has none of these problems.

Martin
Closed Thread


Similar C / C++ bytes