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?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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
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
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

jasonclarkeCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.