[Bug libstdc++/52447] New: Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[Bug libstdc++/52447] New: Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[john.unsworth at criticalpath dot net]

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

             Bug #: 52447
           Summary: Application crashes on SLES11 when using
                    libstdc++.so.6.0.10 but runs fine with 6.0.8
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: john.unsworth@criticalpath.net


We build our application with gcc version 3.4.6 20060404 (Red Hat 3.4.6-11).

On SLES 11 using libstdc++ 6.0.10 we get this crash when loading application
shared library libmuwssoap.so:

Program terminated with signal 11, Segmentation fault.
#0  0xb7c3d8c0 in ?? () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb7c3d8c0 in ?? () from /usr/lib/libstdc++.so.6
#1  0xb7bc35aa in bool std::has_facet<std::ctype<char> >(std::locale const&) ()
from /usr/lib/libstdc++.so.6
#2  0xb7bb77d8 in std::basic_ios<char, std::char_traits<char>
>::_M_cache_locale(std::locale const&) () from /usr/lib/libstdc++.so.6
#3  0xb7bb7887 in std::basic_ios<char, std::char_traits<char>
>::init(std::basic_streambuf<char, std::char_traits<char> >*) () from
/usr/lib/libstdc++.so.6
#4  0xb7ba2196 in std::ios_base::Init::Init() () from /usr/lib/libstdc++.so.6
#5  0xb60ba7ab in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535)
    at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/iostream:77
#6  0xb60ba800 in global constructors keyed to _ZN23MetaUniversalWebServiceC2Ev
() at MUWSService.cpp:90
#7  0xb60ba829 in __do_global_ctors_aux () from
/opt/criticalpath/common/bin/libmuwssoap.so
#8  0xb609fb89 in _init () from /opt/criticalpath/common/bin/libmuwssoap.so
#9  0xb7fd2db4 in ?? () from /lib/ld-linux.so.2
#10 0xb7fd2ee4 in ?? () from /lib/ld-linux.so.2
#11 0xb7fd6ebb in ?? () from /lib/ld-linux.so.2
#12 0xb7fd29f6 in ?? () from /lib/ld-linux.so.2
#13 0xb7fd666c in ?? () from /lib/ld-linux.so.2
#14 0xb7c43c4f in ?? () from /lib/libdl.so.2
#15 0xb7fd29f6 in ?? () from /lib/ld-linux.so.2
#16 0xb7c4411c in ?? () from /lib/libdl.so.2
#17 0xb7c43b81 in dlopen () from /lib/libdl.so.2
#18 0xb7d2dc4b in LoadLibrary (sName=0x832d6c4) at unix.cpp:377
#19 0xb6229ece in CUniversalPlugIn::Initialize (this=0x832d090,
sPrefix=0x832d068, sPlugInFileName=0xbf8ddaa0, sDependencyList=0xbf8dd690)
    at CUniversalPlugin.cpp:128

We reverted to 6.0.8 and it loads and runs with no problems.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.3.2

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-03-01 11:13:15 UTC ---
6.0.10 is from GCC 4.3 which is no longer supported here, if you want a change
to that version you should report it to SUSE

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-03-01 11:14:26 UTC ---
Also, nothing will happen without a testcase to reproduce the problem, see
http://gcc.gnu.org/bugs/

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-03-01
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-01 11:34:26 UTC ---
Also as you report the issue for two different vendor versions it is necessary
to known how GCC (and thus libstdc++) was configured.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[john.unsworth at criticalpath dot net]

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

--- Comment #4 from John Unsworth <john.unsworth at criticalpath dot net> 2012-03-01 11:49:12 UTC ---
Can you confirm that applications built on Red Hat with:

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)

should work on SLES 11 with the standard libstdc++ on that system which is
6.0.10? Or do we need to ensure that 6.0.8 is used?

Producing a test case will be hard because it is a large application using many
shared libraries.

Thank you.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-01 12:05:29 UTC ---
(In reply to comment #4)
> Can you confirm that applications built on Red Hat with:
> 
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)
> 
> should work on SLES 11 with the standard libstdc++ on that system which is
> 6.0.10? Or do we need to ensure that 6.0.8 is used?

SLE11 SP1 gcc is configured like

../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
'--with-pkgversion=SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux

which looks compatible.  So yes, it should work.

I am assuming you are on a 32bit host.  Please clarify if you built
on a 32bit host but are running on a 64bit host with 32bit libs.

> Producing a test case will be hard because it is a large application using many
> shared libraries.

It might be that the new libstdc++ uses TLS for thread-safe init and the
old one not and that you are hitting a dynamic linker bug so that TLS is
not properly initialized when the application dlopens libmuwssoap.so.

You have to debug this further yourself if you do not have a testcase.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[john.unsworth at criticalpath dot net]

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

--- Comment #6 from John Unsworth <john.unsworth at criticalpath dot net> 2012-03-01 12:16:18 UTC ---
The application is 32 bit and we build on a 32 bit linux Linux version
2.6.9-89.ELsmp. We are running on 64 bit SLES11.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu.org

--- Comment #7 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-04-25 02:35:21 UTC ---

Hmm. Reviewing this bug report, I see static initialization issues in large C++
projects, with many dependencies, involving three older and unsupported (from
the FSF perspective) toolchains, and no testcase.

To review:
gcc-3.4 ish = 6.0.3
gcc-4.1 ish = 6.0.8
gcc-4.3 ish = 6.0.10

Static locals got reworked at 4.0, so if you can run w/o error on 6.0.8 it's
probably not that. (Behaviour can be reverted w/ -fno-threadsafe-statics if you
are feeling like testing this.)

Without additional input, we're not going to be able to help you resolve this,
sorry. 

That might be ok for you, if  this was just a general "is this supposed to
work/are there known bugs" query. You have an answer.

If you are trying to get to the bottom of this, here are some things that might
be useful:

1) a way to reproduce, using one of the toolchain releases that is marked as
active on the gcc web site. Without this, I'm afraid we'll have to close this
bug report, and intend to do so after May 1, 2012.

2) porting to gcc-4.4/libstdc++.so.6.0.11+, instead of gcc-4.3. Gcc-4.4 was a
more widely deployed gcc release, and it is likely that integration issues with
the older (at this point, quite old) system environment may be better
understood. Those packages might be more polished, so maybe you'll just get
lucky.

You might want to see if SLES 11 has an alternate/newer compiler packaged
directly by the vendor, or use the opensuse gcc44 package. There may be a
subtle integration issue unknown to you.

[Bug libstdc++/52447] Application crashes on SLES11 when using libstdc++.so.6.0.10 but runs fine with 6.0.8

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #8 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-05-02 17:13:08 UTC ---

Re-open if present in self-contained testcase.