Recent strstream regression: reversion needed?

[Paolo Carlini]

Benjamin, all,

we have got a regression report:

    http://gcc.gnu.org/ml/gcc/2002-05/msg02967.html

which I have confirmed, on x86-linux: the seg fault happens when 
strtreambuf::~strstreambuf() is called.

Today, two hours of work after my *wrong* analysis of yesterday, I'm 
sure that the culprit is in fact the following commit:

2002-05-15  Benjamin Kosnik  <bkoz@redhat.com>

        PR libstdc++/6594
        * src/strstream.cc (strstreambuf): Fix leak.

Why I think so? The reason is in strstreambuf::~strstreambuf():

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);
}

During the execution of the testcase overflow() is called: the original 
buffer _M_buf is *disposed* and a new one allocated (sized 32 = 2 x 16), 
pointed by eback(). Therefore, in general, even when p != _M_buf it is 
*no* good to call _M_free(_M_buf), and in fact, it seems to me, 
completely unnecessary.

Honestly, I believe that the correct fix is simply reverting the commit 
for libstdc++/6594.

I should point out that the latter still doesn't make sense to me: the 
_M_free(eback()) call present in the original ~strstreambuf() is 
perfectly able to free the allocated memory (16 chars, 32 chars or 
whatever).

Ciao, Paolo.

P.S. In order to collect the required information (overflow, 
reallocations, addresses of the various buffers) I had to put manually a 
few printf in strstream.cc :( Perhaps someone may give me some advices 
on how to make good use of gdb in such situations...