This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 51113 - ostrstream in c++ lib has a memory leak
ostrstream in c++ lib has a memory leak
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: libg++ (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-07 09:55 EDT by Jeremy Sanders
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-07 11:46:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Jeremy Sanders 2001-08-07 09:55:18 EDT
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 11:23:12 EDT
Created attachment 26653 [details]
Patch to gcc sources to fix problem (untested)
Comment 2 Jeremy Sanders 2001-08-07 11:42:29 EDT
Created attachment 26654 [details]
previous patch was reversed
Comment 3 Jeremy Sanders 2001-08-07 11:46:05 EDT
Created attachment 26655 [details]
third time lucky!!!
Comment 4 Jakub Jelinek 2001-08-08 06:19:33 EDT
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 06:48:48 EDT
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 13:23:22 EDT
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.