libstdc++/8636: global ostringstreams lose their data

libstdc++/8636: global ostringstreams lose their data

[michael.pronath]

>Number:         8636
>Category:       libstdc++
>Synopsis:       global ostringstreams lose their data
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 19 05:46:05 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     michael.pronath@gmx.de
>Release:        unknown-1.0
>Organization:
>Environment:
Linux glibc2 g++ 3.2
both in debian package and when compiled from source
>Description:
global ostringstreams lose their data after calling
c_str on them when new memory is allocated.
See appended example.
Expected output: Hello World, where are you?
real output:     Hello Hello Hello Hello Hell

reason: when fillmystream() returns, the ostringstream content is forgotten, just like it was an automatic
variable.  The string operator+= then allocates new memory
for extension of the string and gets the address of x and
then appends itself.

Interestingly, this does not happen in valgrind.
>How-To-Repeat:
g++ -o teststream teststream.cc
./teststream
valgrind ./teststream
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="teststream.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="teststream.cc"

I2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8c3N0cmVhbT4KI2luY2x1ZGUgPHN0cmluZz4K
CnVzaW5nIG5hbWVzcGFjZSBzdGQ7Cgpvc3RyaW5nc3RyZWFtIHRlc3RzdHJlYW07CmNvbnN0IGNo
YXIgKng7Cgp2b2lkIGZpbGxteXN0cmVhbSgpCnsKICAgdGVzdHN0cmVhbSA8PCAiIFdvcmxkLCB3
aGVyZSBhcmUgeW91PyI7CiAgIHggPSB0ZXN0c3RyZWFtLnN0cigpLmNfc3RyKCk7CiAgIHJldHVy
bjsKfQogICAKaW50IG1haW4oKQp7CiAgIHN0cmluZyB0ZXN0c3RyaW5nPSIiOwogICBmaWxsbXlz
dHJlYW0oKTsKICAgdGVzdHN0cmluZyA9ICJIZWxsbyAiOwogICB0ZXN0c3RyaW5nICs9IHg7CiAg
IGNvdXQgPDwgInRlc3RzdHJpbmcgaXMgJyIgPDwgdGVzdHN0cmluZyA8PCAiJyIgPDwgZW5kbDsK
fQoK

Re: libstdc++/8636: global ostringstreams lose their data

[Michael Pronath]

The following reply was made to PR libstdc++/8636; it has been noted by GNATS.

From: Michael Pronath <michael.pronath@gmx.de>
To: Paolo Carlini <pcarlini@unitus.it>
Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
        nobody@gcc.gnu.org
Subject: Re: libstdc++/8636: global ostringstreams lose their data
Date: 21 Nov 2002 13:11:49 +0100

 Hello again,
 I think I found the reason for this, it's not a bug.
 
 If 'oss' is an ostringstream, then calling
 
   x = oss.str().c_str();
 
 is a bad idea, because oss.str() returns a copy of the contents of oss
 by value, i.e. a temporary value that is free'd right after this
 statement.  Therefore x is invalid, pointing to a free'd memory region.
 
 --> oss.str().c_str() will always return a pointer to a temporary
     value.
     For example, strcpy(dest, oss.str().c_str()) would work, but
     not   x=oss.str().c_str(); strcpy(dest,x);
 
 I believe this is ok with the standard.
 Sorry, my fault.
 
 Regards,
 Michael
 

Re: libstdc++/8636: global ostringstreams lose their data

[Paolo Carlini]

The following reply was made to PR libstdc++/8636; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org,  gcc-bugs@gcc.gnu.org, 
 nobody@gcc.gnu.org
Cc: michael.pronath@gmx.de
Subject: Re: libstdc++/8636: global ostringstreams lose their data
Date: Thu, 21 Nov 2002 11:53:59 +0100

 Yes, the problem is present with g++-3.0, g++-3.2 and g++-3.2.1
 all with glibc2.3.1
 
 Debian system:   libc6_2.3.1-3
                   g++-3.2_3.2.1-0pre2
                   g++-3.0_3.0.4-7
                   libstdc++5-dev_3.2.1-0pre2
 
 Redhat system:   glibc-devel-2.1.3-22
 		 glibc-2.1.3-22
                   g++-3.2   self-made
 
 The original topic was wrong, I found an even simpler example, it's got
 nothing to do with global/local variables; it's probably in the
 allocator:
 
 -----------------------------------------------------------------------
 #include <iostream>
 #include <sstream>
 #include <string>
 
 using namespace std;
 
 int main()
 {
      const char *x;
      ostringstream teststream;
      string teststring="";
      teststream << "World, where are you?";
      x = teststream.str().c_str();
      teststring = "Hello ";
      teststring += x;
      cout << "teststring is '" << teststring << "'." << endl;
      cout << "teststream.str() is '" << teststream.str() << "'." << endl;
      cout << "teststring.data() is at 0x" << hex << (int) teststring.data()
 	 << ", x is at 0x" << hex << (int) x << endl;
      cout << "teststream.str().c_str() is at 0x" << hex
 	 << (int) teststream.str().c_str() << endl;
 }
 ------------------------------------------------------------------------
 
 
 g++-3.2 -o teststream teststream.cc
 
 ldd teststream
 	libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4001a000)
 	libm.so.6 => /lib/libm.so.6 (0x400c4000)
 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400e5000)
 	libc.so.6 => /lib/libc.so.6 (0x400ed000)
 	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 
 Unexpected output:
 teststring is 'Hello Hello Hello Hello Hello Hel'.
 teststream.str() is 'World, where are you?'.
 teststring.data() is at 0x804a99c, x ist at 0x804a99c
 teststream.str().c_str() is at 0x804a94c
 
 
 I thinks it's that the operator+= of string is resizing the string
 because it needs new space to append.  From the allocator, it receives
 the address of "x" as if this space was already freed by the
 ostringstream (don't know why).  Then the string appends its data to
 itself, which leads to the repeating Hello.
 
 
 Regards,
 Michael
 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8636
 

Re: libstdc++/8636: global ostringstreams lose their data

[paolo]

Synopsis: global ostringstreams lose their data

State-Changed-From-To: open->feedback
State-Changed-By: paolo
State-Changed-When: Wed Nov 20 04:48:35 2002
State-Changed-Why:
    Cannot reproduce on x86-linux (glibc2.3.1) with gcc-3.2.1
    and current 3.3 exp. Could possibly install gcc-2.3.1 and
    see if the problem it's still present for you?
    Thanks, Paolo.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8636