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 <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. -- 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