[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Apps linked with old libstdc++ dlopening modules linked with the new one

On Wed, Sep 14, 2005 at 02:39:55AM -0700, Steve Langasek wrote:
> On Wed, Sep 14, 2005 at 09:33:17AM +0200, Enrico Zini wrote:
> > > On Tue, Sep 13, 2005 at 08:31:55PM +0200, Enrico Zini wrote:
> > > > <short summary>
> > > > Applications linked with libstdc++5 and using GTK segfault when using
> > > > SCIM[1] as input method, and neither GTK nor SCIM nor the apps seem to
> > > > be to blame.
> > > > </short summary>

> > Please find attached the backtraces and edited straces of oowriter,
> > epiphany and drgeo.

> Ok, this shows a crash when calling into libstdc++6 from libscim;
> there's at least no evidence of symbol mixing in the backtrace, which is
> good, but it also doesn't clarify why the failure is happening.

> If I set suitable breakpoints, though, I can get a backtrace that looks
> like this from drgeo:

> Breakpoint 3, 0xb78c9126 in operator new () from /usr/lib/libstdc++.so.5
> (gdb) bt
> #0  0xb78c9126 in operator new () from /usr/lib/libstdc++.so.5
> #1  0xb78b58bb in std::__default_alloc_template<true, 0>::_S_chunk_alloc ()
>    from /usr/lib/libstdc++.so.5
> #2  0xb78b57cd in std::__default_alloc_template<true, 0>::_S_refill ()
>    from /usr/lib/libstdc++.so.5
> #3  0xb78b54c8 in std::__default_alloc_template<true, 0>::allocate ()
>    from /usr/lib/libstdc++.so.5
> #4  0xb78bae58 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.5
> #5  0xb78baf2e in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.5
> #6  0xb78b8b4d in std::string::reserve () from /usr/lib/libstdc++.so.5
> #7  0xb78b8eb4 in std::string::append () from /usr/lib/libstdc++.so.5
> #8  0xb78bb11b in std::operator+<char, std::char_traits<char>, std::allocator<char> > () from /usr/lib/libstdc++.so.5
> #9  0xb70a3420 in scim::FrontEndModule::FrontEndModule ()
>    from /usr/lib/libscim-1.0.so.8
> <snip>

> And libscim-1.0.so.8 definitely does *not* depend on any symbols which
> should be resolvable via libstdc++.so.5, so... that smells like a linker
> bug.

A bit of digging on IRC:

<vorlon> well, that's the one it's calling from libstdc++6... let
         me see what symbol it's looking up from 5
<vorlon> ok, maybe the only symbol it's looking for there is
<vorlon> which is the operator+ symbol in my mail
<asuffield> asuffield@cyclone:~$ objdump -T /usr/lib/libscim-1.0.so.8 | grep
<asuffield> 0003af90  w   DF .text  00000051  Base        _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_
<asuffield> fuck
<asuffield> what is that doing there?
<vorlon> ah, cute
<asuffield> problem explained
<vorlon> yep
<vorlon> not really fixed, though
<asuffield> having seen the call for this unversioned node, the linker
            picks one at random
<asuffield> so, the problem is caused by template instantiation shoving
            this symbol into the library that uses it
<asuffield> the two possible solutions are (a) stop doing that, or (b)
            version the symbol
<vorlon> so that's a g++ bug?
<asuffield> maybe
<asuffield> there are several other unversioned libstdc++ symbols
            in this library
<asuffield> so it's not just a corner case, this is a recurring
<vorlon> fun
<asuffield> we will only notice it during a libstdc++ transition though
<vorlon> yep
<asuffield> I think we start by assuming it's a libstdc++ bug and let
            the g++ folk chew on it

So: g++ is embedding an unversioned weak symbol in the library in some
cases, which causes the linker to resolve it to the version from the lib
used by the app, not the one that the library is linked against.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: