[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 09:33:17AM +0200, Enrico Zini wrote:
> On Tue, Sep 13, 2005 at 12:12:13PM -0700, Steve Langasek 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>
> > Can you provide a full backtrace here?  At least for drgeo, it seems
> > that the only symbols it uses from libstdc++5 are new and delete, and as
> > all symbols exported by libstdc++5 and libstdc++6 are versioned it
> > shouldn't matter *which* symbols are used, the application should still
> > be segfault-proof on this point.

> 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

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

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: