The patch file gcc31-libstdc++-pr6594.patch.bz2 is incorrect and causes a double free in normal useage of the strstream class. I was experiencing crashing while running CMake in the process of building the VTK system (www.kitware.com), and traced the problem to the strstream class. After analyzing the patch, I emailed the author of the patch, and he said that it has been fixed in the gcc-3.1 branch. If nobody knows of a reason to keep the patch, I suggest removing it from the gcc-3.1 build. I can provide more details if requested.
I just looked at the current gcc-3.1 CVS branch, and it does look like it's been fixed. The fix is in the destructor. The patch shows: @@ -140,6 +140,8 @@ strstreambuf::~strstreambuf() { if (_M_dynamic && !_M_frozen) _M_free(eback()); + if (_M_buf) + _M_free(_M_buf); } CVS shows: strstreambuf::~strstreambuf() { if (_M_dynamic && !_M_frozen) { char* p = this->eback(); _M_free(p); if (p == _M_buf) _M_buf = 0; } if (_M_buf) _M_free(_M_buf); } The case of the double free was when eback() == _M_buf, which is now fixed.
Brian, What's the solution here? Shall we use a CVS version of strstream.cc? How about the rest of the patch at: @@ -64,13 +64,13 @@ strstreambuf::strstreambuf(streamsize in _M_alloc_fun(0), _M_free_fun(0), _M_dynamic(true), _M_frozen(false), _M_constant(false) { - streamsize n = max(initial_capacity, streamsize(16)); - - char* buf = _M_alloc(n); - if (buf) { - setp(buf, buf + n); - setg(buf, buf, buf); - } + _M_buf_size = _M_buf_size_opt = max(initial_capacity, streamsize(16)); + _M_buf = _M_alloc(_M_buf_size); + if (_M_buf) + { + setp(_M_buf, _M_buf + _M_buf_size); + setg(_M_buf, _M_buf, _M_buf); + } }
The patch supposedly fixed a memory leak, but I'm not sure there really was a memory leak. The setg call stores buf (in the old patch) in _M_in_beg, which is returned by eback(), so it does get freed in the destructor. This is what was causing the double free. There may be some cases that are leaking memory, but I don't think it's as easy a just stealing pieces from the CVS version. It looks like the CVS version has changed fairly considerably. I would suggest just eliminating the patch from the build and assuming it will get fixed (if there really is a bug to fix) when gcc-3.1.1 is released.
okay, tomorrow i will take the patch out, create a new -r for gcc and mask it. i'd like to hear back if you unmask it and it fixes your problem.
i'm assuming this is no longer a problem in gcc3.2.
