Who manages pointer from stringstream::str()?

We are experiencing a memory leak with "stringstream::str()" and I am not sure if this is a leak in our STL implementation or if we are suppossed to manage the memory returned. The call to "stringstream::str()" below leaks:

#include <iostream>
#include <string>
#include <sstream>

int main()
{
    while ( true )
    {
        ostringstream ss;
        ss << "Hello World!" << ends;
        string s( ss.str() );
    }
    return 0;
}

If we remove the call to "stringstream::str()" or assign the return value to a "char*" pointer and then call "delete" on it, the leak goes away.

What I don't understand is, doesn't "stringstream::str()" work like "string::c_str()", where it's just giving you a pointer to the internal memory it manages? If not, then what is the "correct" way of handling the returned memory? Should I put it into an "auto_ptr"?

This leaks on using the Sun C++ 4.2 compiler on Solaris 2.6. The STL implementation is provided by ObjectSpace. I was not able to reproduce the leak using VC++ 6.0.

Thanks!

magentaAsked:
Who is Participating?
 
jasonclarkeConnect With a Mentor Commented:
But the important point is the difference between stringstream and strstream, strstream deals with char* and hence you have to control the memory allocation.

stringstreams use strings, hence this problem goes away.  freeze is not a member of the string buffer class for a stringstream.
0
 
magentaAuthor Commented:
Although I use "ostringstream" in the code example, it leaks even with "stringstream".

0
 
jasonclarkeCommented:
I think your code is correct, i.e. the implementation is wrong.  str() is supposed to return a string, hence you don't need to worry about the memory, it is owned by the string.  
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
s_franklinCommented:
I have worked with ostrstream and it has problems freeing resources. This exact leak is what I have encountered although under different circumstances.

Typically, the leak rears its head when you want to reuse an ostrstream and you do the following to free up the allocation of the ostrstream:

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

Give that a try with your stringstream - the commands I've mentioned above should give you all the information you need to figure out what's going on. They document their purpose and will explain why the stringstream doesn't free things up the way you might expect.

Steve
0
 
s_franklinCommented:
Good catch - that's what I get for breezing through the question too quickly.
0
 
nietodCommented:
The code is correct and should not produce any leaks--in a sense.  You have an infinite loop there.  When that loop ends the memory used by the stream and string will be freed and there will be no leaks.  But the loop never ends.....

When i compile the code without the loop, just with the contents of the loop, there are no leaks.
0
 
s_franklinCommented:
For fun, I would try explicitly controlling instantiation and destruction of the stringstream object within the loop.

Try 'new'-ing and 'delete'-ing your ostringstream explicitly within each iteration of the while loop and see if your leak goes away. It shouldn't, but that doesn't mean that your environment isn't doing something funny with typical scoping rules in this case.

Steve
0
 
s_franklinCommented:
By the way, have you tried a tool like Rational's Purify to get more data on the nature and source of the memory leak? You can find and evaluate this product via the following URL:

http://www.rational.com/products/purify_nt/index.jtmpl

(Note that you can get to the Unix versions from the above URL).

Steve
0
 
magentaAuthor Commented:
According to the man page, strstream::str() returns a char* and the caller must free the returned memory. So the code sample is not a bug, it is correctly leaking.

However, I am using stringstream, not strstream but it turns out that ObjectSpace STL typedefs stringstream as strstream, so they are essentially the same class.

Under VC++, strstream::str() returns a char*, which must be freed by the caller. stringstream::str() returns a basic_string and therefore, does not need to be freed. I hope that when we use Sun C++ 5.0 that stringstream acts the same way.

Anyway, thanks everyone for your input!

0
All Courses

From novice to tech pro — start learning today.