Recent strstream regression: reversion needed?

Michael Veksler VEKSLER@il.ibm.com
Sat Jun 1 23:11:00 GMT 2002


Reverting PR libstdc++/6594 fixes the regression. 

The problem that PR6594 tries to fix looks real. It should be fixed correctly
(after reverting the original "fix").

 Thanks
    Michael
Please respond to Paolo Carlini <pcarlini@unitus.it> 
To:     libstdc++@gcc.gnu.org
cc:     bkoz <bkoz@redhat.com>, Michael Veksler/Haifa/IBM@IBMIL, Joe Buck 
<Joe.Buck@synopsys.com> 
Subject:        Recent strstream regression: reversion needed?



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...





More information about the Libstdc++ mailing list