Bug 51113 - ostrstream in c++ lib has a memory leak
Summary: ostrstream in c++ lib has a memory leak
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libg++
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-07 13:55 UTC by Jeremy Sanders
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-08-07 15:46:09 UTC
Embargoed:


Attachments (Terms of Use)
Patch to gcc sources to fix problem (untested) (444 bytes, patch)
2001-08-07 15:23 UTC, Jeremy Sanders
no flags Details | Diff
previous patch was reversed (444 bytes, patch)
2001-08-07 15:42 UTC, Jeremy Sanders
no flags Details | Diff
third time lucky!!! (484 bytes, patch)
2001-08-07 15:46 UTC, Jeremy Sanders
no flags Details | Diff

Description Jeremy Sanders 2001-08-07 13:55:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801

Description of problem:
Using the ostrstream class in the c++ standard library causes a memory
leak. If a program uses a lot of them, then all the computer's memory can
be swallowed.

I'll include a test program to demonstrate.



How reproducible:
Always

Steps to Reproduce:
1. Make program using ostrstream
2. Use the str() method to get a const char* to the string
3. Destructor doesn't clear memory
	

Additional info:

Test program (eg test.cc):

#include <iostream>
#include <strstream>

int main()
{
  while(1)
  {
    std::ostrstream o;
    o << "Hello, world!" << '\0';
    
    std::cout << o.str();
  }
}


Compile with g++ test.cc
Run a.out
Watch memory usage of program increase.

This is a serious bug for c++ developers.

There's a workaround. Add

o.rdbuf()->freeze(0);

before the destructor is called.

Comment 1 Jeremy Sanders 2001-08-07 15:23:12 UTC
Created attachment 26653 [details]
Patch to gcc sources to fix problem (untested)

Comment 2 Jeremy Sanders 2001-08-07 15:42:29 UTC
Created attachment 26654 [details]
previous patch was reversed

Comment 3 Jeremy Sanders 2001-08-07 15:46:05 UTC
Created attachment 26655 [details]
third time lucky!!!

Comment 4 Jakub Jelinek 2001-08-08 10:19:33 UTC
I think libstdc++ is right:
http://www.cygnus.com/pubs/gnupro-97r1/4_GNUPro_Libraries/c_The_GNU_C++_Iostream_Library/libio.html
sais in ostrstream::str () description that it
Implies ostrstream::freeze().
This means that after o.str() the string is managed by user who is responsible
for freeing it, unless o.freeze(0) is called.
You could e.g. stick the pointer returned by o.str() into global variable
and use it far after o has been destructed.
Note that g++ 3.0 works exactly the same way with your example, it leaks memory
too. But it is because of missing o.freeze(0) in your testcase.

Comment 5 Jeremy Sanders 2001-08-08 10:48:48 UTC
Interesting, it seems there's some debate whether this is a bug or not. For
example, in the following link Compaq "fixed" their library to free the memory:

http://www.physik.rwth-aachen.de/group/IIIphys/compute/cplusplus/cxx611_release.html

I think however, it's not a bug, after doing some research.

The solution, I suppose is to use ostringstream, but that's only a recent
addition to the standard :-(


Comment 6 Jakub Jelinek 2001-08-08 17:23:22 UTC
My reading of the link you provided is that they weren't freeing the string
at all. ISO C++ in [depr.strstreambuf] sais clearly that the string should
be deleted only if strmode & allocated != 0 and strmode & frozen == 0.
In your testcase, strmode & frozen != 0, so it should not be deleted.


Note You need to log in before you can comment on or make changes to this bug.