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

> Since various days I've been experiencing weird and annoying crashes on
> openoffice and epiphany.  I was kind of ignoring them, but now I need to
> prepare some slides for a presentation and I can't ignore them anymore.

> I checked on the bts, and noone seems to have experienced the same.

> I checked the deps looking for something strange and related, and all
> the crashing apps Depend on libstdc++5.  I checked among other packages
> depending on libstdc++5 and I found I had drgeo installed, which crashed
> as well.  Other non-GTK packages linking libstdc++5 (such as rig or
> guessnet) were unaffected.

> So I straced and gdb-ed, and I found that the crash happens in
> libstdc++6.  But ldd shows the apps don't link libstdc++6.  It turned
> out that the crashes happened in SCIM code, which was linked to
> libstdc++6.

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.

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: