Re: std::stringstream definitely leaks memory (was: Memory leak inios.cc:326)

[Benjamin Kosnik <bkoz at redhat dot com>]

>Did someone open a PR for this?

You just did, thanks.

>It is a very serious bug / regression, not even related
>to threads.  ostringstream simply leaks 76 bytes per
>creation/destruction.

It's related to the locale cache bits that went in. Jerry, can you take
a look at this for the 3.3 branch code? 

>I must add that the fact that this allocation (via
>std::allocator!) is done at all gives me major headaches;
>As you know I maintain a C++ debugging library for
>the GNU compiler (doesn't work with another compiler),
>that support ostream debugging output.
>
>The problem that the above allocation gives me is that
>when anything is allocation memory via std::allocator,
>then a lock is set before 'new' is called, causing subsequent
>calls to std::allocator to dead lock.  In other words,
>I can't anymore create a stringstream<my_allocator> now
>during my debug output because that suddenly (always)
>allocates 73 bytes via std::allocator!  It did NOT do
>that with g++-3.2 and the libstdc++ version that belongs
>to that release.
>
>I hope somehow that while fixing the above memory leak,
>it will turn out to be possible not to allocate memory
>at all via std::allocator anymore...

The allocations you are seeing are the string data members in the locale
cache. For 3.4, this has to be fixed so that the standard stream objects
can be created with pre-allocated memory, so the current 3.4
implementation is also flawed with respect to that (related) issue.

I didn't have a working valgrind on my system when this stuff went in,
so I didn't catch it then.

I'm halfway through a zero-allocation patch for mainline, but I'd like
to stop working on it for the moment and finish the testsuite work
before Paolo adds yet more test cases, and merging becomes yet more
complicated.

-benjamin