From: whm@sunquest.UUCP (Bill Mitchell)
Newsgroups: comp.lang.c++
Subject: Re: ostrstream problem? -- Purify shows a problem in Sun's 2.0
Date: 16 Oct 92 01:35:43 GMT
Organization: Sunquest Information Systems, Tucson

In article <1992Oct13.154928.18846@exu.ericsson.se>, exudch@exu.ericsson.se (Doug Hurtig, t/foj, (214) 997-6571) writes:
> I have an application running on a Sun 4.1.1 system that uses
> ostrstream to build up a charater array.  Once I have built the array
> I use "str" to get a pointer to the charater array and to freeze the
> array. It is my understanding that I am responsible for releasing the
> memory once the "str" function is called.
>  
> During testing of this code I have noticed that when the destructor
> is called several bytes are appended to the array returned by str.
> This is a problem in that the array has already been freed. In my real 
> application this memory has already been reallocated by time the ostrstream
> destructor is called.
> 

There appears to be a bug in ostrstream in Sun's library for "Sun C++ 2.0
FCS - 10/20/89" but not in their SC1.0, which is 2.1, I believe.

Consider this program:

#include <strstream.h>

main(int argc, char **)
{
    ostrstream buf;

    buf << "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" << ends;

    char *p = buf.str();
    if (argc == 2)
        delete p;
}

If a command line argument is specified, it frees the memory turned over by
ostrstream::str.

Here's purify output when run with a command line argument (causing the
"delete p" to be done).

Purify 1.0.3 (04/14/92) (C) 1990-92 Pure Software Inc.  Patents Pending.
Contact us at support@pure.com or (415) 903-5100.
Purify license checked out.
(Purify...reading symbol table...shared libraries...sorting...Done.)

 ------ a.out ------ 
Error: Free Memory Write (frw) violation while in:
             ostrstream::~ostrstream() (<shared library>; pc = 0xf75ed7b8)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebf8)
             start (usr_lib_crt0.o; pc = 0xe63c)

Details: Writing 1 byte to 0x256ea (in freed memory).
The address 0x256ea is 58 bytes into a freed chunk 64 bytes long,
that begins at 0x256b0, and was allocated by malloc, called from:
             operator new(unsigned int) (<shared library>; pc = 0xf75e00bc)
             strstreambuf::doallocate() (<shared library>; pc = 0xf75ebdf8)
             strstreambuf::overflow(int) (<shared library>; pc = 0xf75ec054)
             ostream::operator<<(const char*) (<shared library>; pc = 0xf75e1c00)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xeb54)
             start (usr_lib_crt0.o; pc = 0xe63c)
This freed array was freed 2 calls to free ago, from:
             operator delete(void*) (<shared library>; pc = 0xf75e01e0)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebe8)
             start (usr_lib_crt0.o; pc = 0xe63c)

 ------ a.out ------ 
Error: Free Memory Write (frw) violation while in:
             streambuf::sync() (<shared library>; pc = 0xf75f1c18)
             streambuf::~streambuf() (<shared library>; pc = 0xf75f2940)
             strstreambuf::~strstreambuf() (<shared library>; pc = 0xf75ec7f0)
             strstreambase::~strstreambase() (<shared library>; pc = 0xf75ecf20)
             ostrstream::~ostrstream() (<shared library>; pc = 0xf75ed7ec)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebf8)

Details: Writing 1 byte to 0x256eb (in freed memory).
The address 0x256eb is 59 bytes into a freed chunk 64 bytes long,
that begins at 0x256b0, and was allocated by malloc, called from:
             operator new(unsigned int) (<shared library>; pc = 0xf75e00bc)
             strstreambuf::doallocate() (<shared library>; pc = 0xf75ebdf8)
             strstreambuf::overflow(int) (<shared library>; pc = 0xf75ec054)
             ostream::operator<<(const char*) (<shared library>; pc = 0xf75e1c00)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xeb54)
             start (usr_lib_crt0.o; pc = 0xe63c)
This freed array was freed 2 calls to free ago, from:
             operator delete(void*) (<shared library>; pc = 0xf75e01e0)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebe8)
             start (usr_lib_crt0.o; pc = 0xe63c)

 ------ a.out ------ 
Error: Free Memory Write (frw) violation while in:
             streambuf::sync() (<shared library>; pc = 0xf75f1c18)
             ios::~ios() (<shared library>; pc = 0xf75e3968)
             ostrstream::~ostrstream() (<shared library>; pc = 0xf75ed824)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebf8)
             start (usr_lib_crt0.o; pc = 0xe63c)

Details: Writing 1 byte to 0x256ec (in freed memory).
The address 0x256ec is 60 bytes into a freed chunk 64 bytes long,
that begins at 0x256b0, and was allocated by malloc, called from:
             operator new(unsigned int) (<shared library>; pc = 0xf75e00bc)
             strstreambuf::doallocate() (<shared library>; pc = 0xf75ebdf8)
             strstreambuf::overflow(int) (<shared library>; pc = 0xf75ec054)
             ostream::operator<<(const char*) (<shared library>; pc = 0xf75e1c00)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xeb54)
             start (usr_lib_crt0.o; pc = 0xe63c)
This freed array was freed 2 calls to free ago, from:
             operator delete(void*) (<shared library>; pc = 0xf75e01e0)
             main (usr_CC_sun4_static-ctor-dtor.o; pc = 0xebe8)
             start (usr_lib_crt0.o; pc = 0xe63c)

---- Purify: a.out exit summary: 3 unsuppressed errors; 0 suppressed errors  -----

Purify: Searching for all memory leaks...
[Remainder deleted -- whm]

If the "delete p" is not done, purify has no complaints.  With the SC1.0 CC,
there are no complaints from Purify with or without the "delete p".

For 2.0, I don't see a solution other than to just leak the memory returned
by str().

Purify plug: Purify is a simply wonderful utility.  It's the sort of sparkling
thing that results when brilliant ideas are well-implemented.  If you're doing
development on Suns, get it.  (There's a phone number and email address above
for Pure Software.)

--------------------------------------------------------------------
Bill Mitchell				whm@sunquest.com
Sunquest Information Systems		sunquest!whm@arizona.edu
4801 E. Broadway                        {arizona,uunet}!sunquest!whm
Tucson, AZ, 85711                       sunquest!whm@uunet.uu.net
602-570-2585

"The more C++ I write, the more I like like Icon."
Newsgroups: comp.lang.c++