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
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_
<vorlon> which is the operator+ symbol in my mail
<asuffield> asuffield@cyclone:~$ objdump -T /usr/lib/libscim-1.0.so.8 | grep
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_
<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
problem
<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.
Segfault.
--
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