[Bug libstdc++/41645] New: Massive failures in parallel test mode

[Bug libstdc++/41645] New: Massive failures in parallel test mode

[chris at bubblescope dot net]

In 'libstdc++-v3', type 'make check-parallel' and a huge number of tests fail.

Some of these are expected, in particular several in 25_algorithm, to do with
lack of c++0x support, but most of the failures seem to be related to a string
problem.

Taking one example
(testsuite/26_numerics/complex/inserters_extractors/char/1.cc), I get the
error:

1.exe(21140) malloc: *** error for object 0x100019ae0: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

And backtrace:

#0  0x00007fff879fdb91 in malloc_error_break ()
#1  0x00007fff87927083 in free ()
#2  0x0000000100094bfa in std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::overflow (this=0x7fff5fbff428, __c=40) at
bits/basic_string.h:236
#3  0x000000010009911c in std::basic_streambuf<char, std::char_traits<char>
>::xsputn (this=0x7fff5fbff428, __s=<value temporarily unavailable, due to
optimizations>, __n=13) at bits/streambuf.tcc:97
#4  0x000000010008f4b5 in std::__ostream_insert<char, std::char_traits<char> >
(__out=@0x7fff5fbff420, __s=<value temporarily unavailable, due to
optimizations>, __n=13) at streambuf:427
#5  0x0000000100053aac in std::operator<< <float, char, std::char_traits<char>
> (__os=@0x7fff5fbff420, __x=<value temporarily unavailable, due to
optimizations>) at bits/basic_string.h:2539
#6  0x000000010000521d in test01 ()
#7  0x0000000100005cd8 in main ()

All the errors seem to be similarly related to string. The standard 'make
check' works fine, as does the compiler in general use. 

This problem seems to be connected to libtestc++.a (If I remove it when
compiling the test, the result works fine), but I am not sufficiently expert on
linking to figure out exactly what is going wrong.


-- 
           Summary: Massive failures in parallel test mode
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: chris at bubblescope dot net
 GCC build triplet: x86_64-apple-darwin10.0.0
  GCC host triplet: x86_64-apple-darwin10.0.0
GCC target triplet: x86_64-apple-darwin10.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-10-09 12:51 -------
Can you sat when did this problem start? Because I'm running again the tests on
x86_64-linux and everything seems in good shape so far (in 23_containers now),
thus I can't confirm it, the problem seems definitely target-dependent...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #2 from chris at bubblescope dot net  2009-10-09 12:57 -------
I shall try to track it down -- it wouldn't suprise me if this is a snow
leopard bug, as there has been a few issues with the default system compiler
switching from 32-bit to 64-bit.


-- 

chris at bubblescope dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2009-10-09 12:59 -------
... for sure the libtestc++.a thing is *very* mysterious...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #4 from chris at bubblescope dot net  2009-10-09 13:21 -------
I have confirmed that after compiling with 'make check-parallel', the code:

#include <string>

int main(void)
{ string s; s = "X"; }

Fails when compiled with: 

/gccsvn/bin/g++ test.cc libtestc++.a -fopenmp

Fails with the same error message.

I wonder if somehow this is connected to:
http://www.cocoabuilder.com/archive/message/cocoa/2009/9/17/245285, which
suggests on snow leopard the standard system library is built differently, with
_GLIBCXX_FULLY_DYNAMIC_STRING enabled. I would assume the system library
shouldn't be used at all however.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2009-10-09 13:52 -------
Indeed, the system library should not be used at all, but in your example above
the system library *is* used unless you make sure to properly install
everything, set the appropriate LD_LIBRARY_PATH, etc. In other terms, I would
be curious to know what happens if you just build everything, install it, and
then use normally the new compiler, for example to compile and run outside the
testsuite some tests... If everything works, it's just some sort of weird
testsuite issue.

PS: in case you didn't notice already, libtestc++.a is built by
v3-build_support in libstdc++.exp, indeed, the system stuff should not be
involved at all...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #6 from chris at bubblescope dot net  2009-10-09 14:16 -------
Ah yes, something I should have tried earlier.

The resulting compiler generally works fine, until I add -D_GLIBCXX_PARALLEL,
when things break.

I only seem to get a problem when I have enough optimisation to inline
functions.

-O0 works fine
-O1 breaks
-O1 -fno-inline works fine

Which is a shame, as it makes debugging that much harder.

The same problem occurs with _GLIBCXX_DEBUG, so actually this isn't related to
parallel, sorry for the false alarm. I assume it's related to extern templates,
but I'm not sure how exactly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #7 from chris at bubblescope dot net  2009-10-09 14:20 -------
Further: If I add -D_GLIBCXX_FULLY_DYNAMIC_STRING, the code compiles fine!

However, if I run otool on my executable, it says it is linked with:

Load command 10
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /newgccsvn/lib/libstdc++.6.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 7.14.0
compatibility version 7.0.0
Load command 11
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /newgccsvn/lib/libgcc_s.1.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 124.1.1
compatibility version 1.0.0


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2009-10-09 14:46 -------
So, the problem is exactly that you *are* using the system libraries, a mix of
the new headers and the system library. This is in general unsupported of
course.

While apparently we *do* have a problem in testsuite, not sure why, it seems to
me that the new installed compiler + libraries should be ok, in parallel mode,
debug mode and everything, assuming you consistently link vs the new libraries,
not the system ones. Can you do that and report back?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2009-10-09 14:51 -------
Sorry, your 'however' confused me. So, you *are* linking versus the new
library, right? In that case it is *incorrect* to pass
-D_GLIBCXX_FULLY_DYNAMIC_STRING in the command line, since your new library has
not been built with it.

As a matter of fact, the use itself of -D_GLIBCXX_FULLY_DYNAMIC_STRING is
**completely** unsupported, in other terms the user is **never** supposed to
pass it, only the configure can internally appropriately set
_GLIBCXX_FULLY_DYNAMIC_STRING basing on --enable-fully-dynamic-string. Somebody
should tell Apple ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #10 from chris at bubblescope dot net  2009-10-09 15:10 -------
To sum up the current state, as things are getting confusing:

Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
testsuite/util -O2'

using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc
4.2.1)

No flags: Fine
-D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails
-D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING :
Works

I built my compiler with:

../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn
make && make install

Using otool -l (an Apple system utility), it looks like when I use the system
compiler I get linked against   /usr/lib/libstdc++.6.dylib, and when I use
/newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib

So there seems to be two issues:

1) Someone in Apple has completely broken their standard library by turning on
_GLIBCXX_FULLY_DYNAMIC_STRING  and worse not putting that in the headers, which
is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other
nastyness.

2) For some reason I cannot figure out, this is somehow 'leaking' into my
build.

Apologises for a few wild goose-cases along the way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #11 from paolo dot carlini at oracle dot com  2009-10-09 15:31 -------
(In reply to comment #10)
> To sum up the current state, as things are getting confusing:

A bit yes ;)

> Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
> testsuite/util -O2'
> 
> using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc
> 4.2.1)
> 
> No flags: Fine
> -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails
> -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING :
> Works
> 
> I built my compiler with:
> 
> ../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn
> make && make install
> 
> Using otool -l (an Apple system utility), it looks like when I use the system
> compiler I get linked against   /usr/lib/libstdc++.6.dylib, and when I use
> /newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib

Just out of curiosity, it gets linked magically to the new library without
telling it to do so? On Linux, I need to add the new path to LD_LIBRARY_PATH,
otherwise, it doesn't happen. Any idea how it can be so smart?

> So there seems to be two issues:
> 
> 1) Someone in Apple has completely broken their standard library by turning on
> _GLIBCXX_FULLY_DYNAMIC_STRING  and worse not putting that in the headers, which
> is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other
> nastyness.

Definitely.

> 2) For some reason I cannot figure out, this is somehow 'leaking' into my
> build.

Yes, this is the most mysterious part.

One final remark, then I don't see I can do much about this issue right now, I
wonder if you can get a fully working compiler + libraries, if you just pass
--enable-fully-dynamic-string at build time. That breaks binary compatibility,
note (eg, old binaries cannot work fine linked to the new library), but I
vaguely suspect that this way you would get a more consistent whole.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[chris at bubblescope dot net]

------- Comment #12 from chris at bubblescope dot net  2009-10-09 17:51 -------
LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just
works', but in this case it seems to have broken.

By configuring with --enable-fully-dynamic-string, I get a working compiler
(actually better than the system compiler, as now -D_GLIBCXX_DEBUG works) so
I'm happy for now. Someone who is better with linking-fu than me should
probably at some point look at just what Apple has managed to mess up however.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[joseph at codesourcery dot com]

------- Comment #13 from joseph at codesourcery dot com  2009-10-09 19:42 -------
Subject: Re:  Massive failures in parallel test mode

On Fri, 9 Oct 2009, chris at bubblescope dot net wrote:

> LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just

It's called DYLD_LIBRARY_PATH there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #14 from paolo dot carlini at oracle dot com  2010-01-28 15:23 -------
If I understand correctly at least part of this issue, now the situation should
be somewhat better, because a few days after the original conversation in the
audit trail, I enabled extern templates for parallel mode. Thus, irrespective
of what Apple did exactly, nothing special should happen for a normally built
gcc4.5 library (ie, without anything special about dynamic strings) when
testing normal mode vs parallel mode. Can you check Chris?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645

[Bug libstdc++/41645] Massive failures in parallel test mode

[paolo dot carlini at oracle dot com]

------- Comment #15 from paolo dot carlini at oracle dot com  2010-01-28 16:27 -------
In the meanwhile I have been able to build and run make check-parallel on a
x86_64-apple-darwin10.2.0, and indeed the specific problem seems fixed.

Beyond that, I'm pretty sure a judicious use of DYLD_LIBRARY_PATH and the like
should help solving similar issues in this area.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645