Bug 53838

Summary: _GLIBCXX_DEBUG and empty ostringstream
Product: gcc Reporter: Akim Demaille <akim.demaille>
Component: libstdc++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: normal CC: tom
Priority: P3    
Version: 4.7.1   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description Akim Demaille 2012-07-03 11:31:56 UTC
Hi,

The following program fails on Mac OS X with both 4.7 and 4.8.


$ uname -a
Darwin erebus.lrde.epita.fr 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64

$ g++-mp-4.7 --version
g++-mp-4.7 (MacPorts gcc47 4.7.1_1) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-4.8 --version
g++-mp-4.8 (MacPorts gcc48 4.8-20120701_0) 4.8.0 20120701 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat simpleaut.cc
# define _GLIBCXX_DEBUG 1
# include <sstream>

int main()
{
  std::ostringstream s;
  s.str();
}

$ g++-mp-4.8 tests/unit/simpleaut.cc
$ ./a.out
a.out(28056) malloc: *** error for object 0x10a5f2340: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
zsh: abort      ./a.out


(gdb) bt
#0  0x00007fff89bf582a in __kill ()
#1  0x00007fff89833a9c in abort ()
#2  0x00007fff8989284c in free ()
#3  0x0000000100000b86 in __gnu_cxx::new_allocator<char>::deallocate (this=0x7fff5fbff847, 
    __p=0x1000d0340 "") at ext/new_allocator.h:102
#4  0x0000000100000b58 in std::string::_Rep::_M_destroy (this=0x1000d0340, 
    __a=@0x7fff5fbff89f) at bits/basic_string.tcc:451
#5  0x0000000100000ae6 in std::string::_Rep::_M_dispose (this=0x1000d0340, 
    __a=@0x7fff5fbff89f) at bits/basic_string.h:251
#6  0x00000001000009fd in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7fff5fbffa20) at bits/basic_string.h:541
#7  0x0000000100000968 in main () at tests/unit/simpleaut.cc:7
Comment 1 Jonathan Wakely 2012-07-03 11:52:17 UTC
This is not a GCC bug, please report it to MacPorts not here.

At a guess I'd say you're linking to the system libstdc++.so not the one from your mp builds, and the mp builds do not use the same setting for --enable-fully-dynamic-string as the system libs.
Comment 2 Andrew Pinski 2012-07-03 13:55:05 UTC
Not a GCC bug as Mac OS X's installed libstdc++ is built with --enable-fully-dynamic-string while the mac ports one is not.
Comment 3 Jonathan Wakely 2012-07-03 14:48:38 UTC
Andrew, I'm not actually sure about that, see https://trac.macports.org/ticket/22234

But in any case, it's a problem with MacPorts' GCC package not FSF's GCC.
Comment 4 Akim Demaille 2012-07-19 13:16:23 UTC
Hi People,

I have therefore reported this to MacPorts, see http://trac.macports.org/ticket/35070 .  The outcome is that (i) with --enable-fully-dynamic-string fails to build on MacPorts, and (ii), no, the linking is properly done with the MacPorts' version of stdlibc++:

> also when trying your example the resuling binary is linked to _our_ gcc's C++-lib

So really, there seem to be something weird about this on OS X, as indeed is shown in other tickets.  What course of action would you recommend?
Comment 5 Jonathan Wakely 2012-07-19 13:36:42 UTC
(In reply to comment #4)
> What course of action would you recommend?

I don't understand what the comments in the macports trac mean, but as far as I'm concerned there's nothing for us to do, it's an issue with the macports build, not GCC.

If they want to report a different bug about --enable-fully-dynamic-string that's a separate issue and will be dealt with if it's reported properly.
Comment 6 Tomalak Geret'kal 2015-04-02 23:13:21 UTC
Not a GCC bug? Really? I beg to differ.

 - Bug 54173
 - Bug 33021
 - Bug 64504
Comment 7 Jonathan Wakely 2015-04-03 00:23:18 UTC
One of those bugs is apparently not present in 4.2 or later, are you sure it's the same?

Do you have a reproducible testcase to show the bug, not just "use macports, it breaks"? or only links to other reports that show up for related search terms?
Comment 8 Jonathan Wakely 2015-04-03 00:34:54 UTC
i.e. do you have the exact commands to build a gcc that shows the problem?

So it can be reproduced from a clean source tarball, without external dependencies.