scim-gtk2-immodule will cause apps linked to libstdc++ 5 to crash

Bug #2246 reported by zealubuntu
38
Affects Status Importance Assigned to Milestone
Suse
Fix Released
Unknown
acroread (Ubuntu)
Medium
Matthias Klose
scim (Debian)
Fix Released
Unknown
scim (Fedora)
Fix Released
High
scim (Ubuntu)
Medium
Rolf Leggewie

Bug Description

Having scim-gtk2-immodule installed and set GTK_IM_MODULE=scim, most GTK+ applications that link to libstdc++.so.5 will likely to crash, including mozilla/firefox/thunderbird from mozilla.org, Adobe Reader (acroread) version 7, etc.

The work around is using XIM mode or scim-bridge (needs to have some scim-bridge-* packages installed), by setting GTK_IM_MODULE to xim or scim-bridge, respectively. The correct way to set GTK_IM_MODULE should be using im-switch, but I am not quite sure about the exact im-switch settings in Ubuntu (and I think it changed from release to release).

Revision history for this message
In , Leon (leon-redhat-bugs) wrote :

Description of problem:
When an application links to an old version of libstdc++, symbols collide,
beacuse scim links to the latest version.

Version-Release number of selected component (if applicable):
1.4.0

How reproducible:
everytime

Steps to Reproduce:
1. Install application like acroread 7.0 which use older stdc++
2. acroread

Actual results:
crash

Expected results:
running okay

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

I tried --enable-ld-version-script on RHEL4 where the toolchain is older and
more mature than that in FC4+. It succeeds in allowing openoffice.org to run
(which relies on compat-libstdc++ 3.3 instead of the native 3.4 of RHEL4.
Unfortunately it fails to fix acroread.

According to Su Zhe, acroread has internal symbol conflicts where even
--enable-ld-version-script is unable to fix conflicts. acroread crashes when
you launch it with environment variables disabled but with scim installed. I
suspect this is because it is loading gtk+, which loads the immodule into memory.

Jens mentioned that XIM should still work, but this is doubtful given the above.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

OK... Jens was right. GTK_IM_MODULE=gtk-im-context-simple allows acroread to work.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

--enable-ld-version-script is working in RHEL4 and FC3, but FC4+ it causes total
desktop software failure. Even gdm fails to start and crashes immediately.

We will need Jakub's help on this. There is something about the FC4+ toolchain
or glibc that is causing --enable-ld-version-script built binaries to totally
fail during runtime.

Revision history for this message
In , Jakub (jakub-redhat-bugs) wrote :

Of course you can't mix different libstdc++.so (major) versions within one
program, unless using dlmopen rather than dlopen.
If you limit to C++ without STL (i.e. limit yourself to just <new>, <exception>
and <typeinfo> headers from C++ headers), you could link libsupc++.a statically
and using a version script avoid exporting those symbols to the rest of the
arch.
Otherwise, your only choices are dlmopen (but in that case it would mean
that a lot of libraries would be loaded twice, unless you can squeeze some of
the 20 libraries immmodule.so loads (are they all really necessary?)),
having separate immmodule.so versions depending on libstdc++.so version, not
using C++ for this kind of library at all or running it in a different process
from the main app.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Thanks, Jakub, but that doesn't explain why --enable-ld-version-script
isn't working with FC4 and later, or does it? :)

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

Right, Jakub I believe you misunderstand our problem. We know the limitations
of having more than one libstdc++. --enable-ld-version-script for scim's build
allows it to workaround some (but not all) of those limitations. It works fine
on RHEL4 and SuSE's devel with gcc-4.0.0. There is something different about
FC4's toolchains or glibc that causes scim built in this way to totally fail.
That is the specific issue where we need your help.

Revision history for this message
In , Jakub (jakub-redhat-bugs) wrote :

I don't see how can using a version script for immmodule.so (which is of course a
good thing) and libscim*.so help this. Those libraries link dynamically against
libstdc++.so, so the version script has no influence on what symbols are exported
from other shared libraries. libstdc++.so uses symbol versioning as well, but
if you use STL in the main program linked say with the old libstdc++.so (3.3 and
earlier), whatever makes into the binary and/or its libraries and is being
exported will be unversioned. This results in mixing of incompatible interfaces.
You can be lucky, as you from the above were in RHEL4. You aren't lucky anymore.
That's it.
It all depends on what exact symbols do get used and exported from where and
how they changed. Simply live with the fact that you really can't do this
reliably.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

We are aware that we cannot avoid all problems due to apps that are linked to an
older libstdc++. The problem that we need help solving is the complete failure
of scim when it is built with --enable-ld-version-script, when dealing with only
C and the current version of libstdc++.

Revision history for this message
In , Jakub (jakub-redhat-bugs) wrote :

There are no details here about how it crashes, backtraces etc.
One possible thing could be that some C++ symbols really ought to be always
exported.
Say if you hide using version script
_ZZN9__gnu_cxx20__common_pool_policyINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
and
_ZGVZN9__gnu_cxx20__common_pool_policyINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
and then allocate some object using STL allocator in one shared library and
destroy it in a different library, you lose, as here libstdc++ relies on ODR.
Similarly with other _S_pool variable objects. Also, if you use RTTI, libstdc++
uses simple pointer comparison for RTTI checks; see
/usr/include/c++/4.0*/typeinfo header.
If you hide the typeinfo symbols (I think these are _ZTI* ones) and try to use
RTTI in one shared library on an object created in another shared library, RTTI
might give wrong answers.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

qwang apparently found that RHEL4's libstdc++-3.3 built openoffice.org is not
perfect with the ld version script of libsstdc++-3.4 scim, with scim failing
permanently after a while during usage.

I'm afraid we need to explore other ways of avoiding this problem, because even
if we find the solution to the total failure issue with ld version scripts of
FC4+, it isn't anywhere near good enough to do what we need.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Jakub, upstream told me that this symbol conflict problem will go away
once everyone is using libstdc++ >= 4.0. Is that correct?

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

qwang's finding in Comment #10 turned out to happen with GTK_IM_MODULE=xim too,
so it is unlikely related to this C++ compat issue.

> Jakub, upstream told me that this symbol conflict problem will go away
> once everyone is using libstdc++ >= 4.0. Is that correct?

Isn't it overly optimistic to think that the C++ ABI will never change again? I
also don't like the idea of abandoning compatibility with all apps compiled with
an older C++ compiler.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Warren, comment 11 is just a side question:
whether gcc 4 and later avoid this problem or not.

Revision history for this message
Peter Jochum (peter-jochum) wrote :

I installed it via apt-get(acroread_7.0-0.9_i386.deb) and it starts normal. I don't know what you use pdf for, but just for viewing, evince is a good(free) alternative.

If you installed with adobes rpm or tgz, try the apt-package.

Revision history for this message
zealubuntu (zealubuntu) wrote :

I did install from aptitude. The package is got form breezy/universe

Revision history for this message
Giovanni Condello (nanomad) wrote :

All fine here...

Changed in acroread:
assignee: nobody → motu
Revision history for this message
Ante Karamatić (ivoks) wrote :

Could you please post version of your acroread package, not acroread by it self?

apt-cache show acroread | grep Version

will tell you that. Did you use or do you still use backports repository?

Revision history for this message
Reinhard Tartler (siretart) wrote :

A new package acroread 7.0.1 and will hit the archive soon. Please recheck with that version and please close this bug if it works now.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

https://bugzilla.novell.com/show_bug.cgi?id=85416&x=8&y=7
Novell's equivalent bug where they marked it as "FIXED" despite it being not
perfect.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

From Comment #7, we need details of the complete failure of SCIM under normal
conditions (no mixing of libstdc++ versions) in order for Jakub to be able to
help us diagnose this problem. Setting NEEDINFO_ENG.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :
Download full text (8.0 KiB)

Here is a gdb backtrace with gedit. The backtrace occurs when switching
to SCIM in the IM menu on Button3. This is with scim built configured with
--enable-ld-version-script.

$ gdb gedit
GNU gdb Red Hat Linux (6.3.0.0-1.65rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) r
Starting program: /usr/bin/gedit
(no debugging symbols found)
:
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46912501217584 (LWP 24437)]
(no debugging symbols found)
:
(no debugging symbols found)
Detaching after fork from child process 24441.
(no debugging symbols found)
:
(no debugging symbols found)
Detaching after fork from child process 24444.
GTK Panel of SCIM 1.4.2

*** glibc detected *** /usr/bin/gedit: free(): invalid pointer:
0x0000000000b04d00 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3107b6b0be]
/lib64/libc.so.6(__libc_free+0x6e)[0x3107b6b5ee]
/usr/lib64/scim-1.0/1.4.0/IMEngine/socket.so[0x2aaab6c0370a]
/usr/lib64/scim-1.0/1.4.0/IMEngine/socket.so[0x2aaab6c0608a]
/usr/lib64/scim-1.0/1.4.0/IMEngine/socket.so[0x2aaab6c064c3]
/usr/lib64/gtk-2.0/immodules/im-scim.so[0x2aaab66ac71a]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a58e3f6]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a50e206]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x110)[0x310880ac61]
/usr/lib64/libgobject-2.0.so.0[0x3108818116]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x3ce)[0x3108818e54]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x31088194d2]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a5d8328]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a5e54c0]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a5e9252]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a5e92cc]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a50e206]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x110)[0x310880ac61]
/usr/lib64/libgobject-2.0.so.0[0x3108818116]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x3ce)[0x3108818e54]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x31088194d2]
/usr/lib64/libgtk-x11-2.0.so.0[0x310a5d8328]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x325)[0x310a50cf3c]
/usr/lib64/libgdk-x11-2.0.so.0[0x3109842951]
/usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1d5)[0x3108625dae]
/usr/lib64/libglib-2.0.so.0[0x3108628a64]
/usr/lib64/libglib-2.0.so.0(g_main_loop_run+0x192)[0x3108628f50]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main+0xa1)[0x310a50c4aa]
/usr/bin/gedit(main+0x211)[0x41ef9e]
/lib64/libc.so.6(__libc_start_main+0xef)[0x3107b1cd1f]
/usr/bin/gedit[0x41e059]
======= Memory map: ========
00400000-0046f000 r-xp 00000000 fd:00 4062283
/usr/bin/gedit
0056f000-0057d000 rw-p 0006f000 fd:00 4062283
/usr/bin/gedit
0057d000-00c25000 rw-p 0057d000 00:00 0 [heap]
3107900000-310791a000 r...

Read more...

Ante Karamatić (ivoks)
Changed in acroread:
status: New → Fixed
Revision history for this message
zealubuntu (zealubuntu) wrote :

I upgrade to latest acroread 7.0.1 today

$ sudo apt-cache show acroread | grep Version
Version: 7.0.1-0.0.ubuntu1

I still got the same problem. If I delete my ~/.adobe, and try to launch the acroread from command line, I can see the GUI shows up for a second and then disappears. The acroread command then returns with a return value "1". (I saw it through echo $?). There is no any error msg printed in my terminal.

I never used backports repository.

Any more information needed?

Thanks.

Revision history for this message
Tobias (mailinglists) wrote :

I've got exactly the same problem with acroread 7.0.1 (breeze deb package with apt-get). Acroread hangs for a second and then just stops, no error message etc.

I've been trying for hours to fix this, even downloaded the binaries from Adobe for versions 7.0.0 and 7.0.1. For all of them there is the same problem, although there were no error messages while running the installers.

Any suggestions?

Revision history for this message
zealubuntu (zealubuntu) wrote :

I also tried to download binaries from Adobe website directly. However, it has the same problem.

But the Adobe's binary (7.0.1) was working fine in Hoary (5.04). After upgrading to Breezy, it stops working.

Changed in acroread:
status: Fixed → New
Revision history for this message
Ante Karamatić (ivoks) wrote :

Please provide output of this command:

apt-cache show libatk1.0-0 libc6 libgcc1 libglib2.0-0 libgtk2.0-0 libpango1.0-0 libx11-6 libxext6 zlib1g libldap2 libstdc++5 | grep Version

and... Did you use mirrormax's backports?

Revision history for this message
zealubuntu (zealubuntu) wrote :

Here it is:

$ apt-cache show libatk1.0-0 libc6 libgcc1 libglib2.0-0 libgtk2.0-0 libpango1.0-0 libx11-6 libxext6 zlib1g libldap2 libstdc++5 | grep Version
Version: 1.10.3-0ubuntu2
Version: 2.3.5-1ubuntu12
Version: 1:4.0.1-4ubuntu9
Version: 2.8.3-0ubuntu1
Version: 2.8.6-0ubuntu2
Version: 1.10.1-0ubuntu1
Version: 1:6.2.1+cvs.20050722-8
Version: 1:6.4.3-3
Version: 1:1.2.3-3ubuntu4
Version: 2.1.30-12
Version: 1:3.3.6-8ubuntu1

And I did not use mirrormax's backports. I don't even know what it is.

If you need more information, please let me know.

Thanks

Revision history for this message
Ante Karamatić (ivoks) wrote :

Ok, that looks OK. Could you strace acroread? Like this:

$ strace acroread &> acroread.strace

And then upload that file somewhere? You could even attach it here.
Thank you.

Revision history for this message
zealubuntu (zealubuntu) wrote : strace file for acroread 7.0.1-0.0.ubuntu1

It is generated through

$ strace /usr/bin/acroread >& acroread.strace

Revision history for this message
zealubuntu (zealubuntu) wrote : strace file for acroread (7.0.1 installed from Adobe's binary package)

It is generated from

$strace /usr/local/Adobe/Acrobat7.0/bin/acroread >& acroread-adobe-bin.strace

Revision history for this message
Ante Karamatić (ivoks) wrote : Re: can not start acroread in breezy

Please, try opening new account on your computer and start acroread as a new user.

Revision history for this message
zealubuntu (zealubuntu) wrote :

I just tried to create a new user in my computer. And then I try to start the "acroread" in the new user account. However, I got exact the same behaivor.

Revision history for this message
Tobias (mailinglists) wrote :

My output from

"apt-cache show libatk1.0-0 libc6 libgcc1 libglib2.0-0 libgtk2.0-0 libpango1.0-0 libx11-6 libxext6 zlib1g libldap2 libstdc++5 | grep Version"

is exactly the same as zealubuntu's above.

I tried the thing with the new user. Whereas before I could not see anything when starting acroread, now I can see at least the splash screen, but after its disappearance nothing happens anymore...

Revision history for this message
zealubuntu (zealubuntu) wrote :

Tobias,

I guess if you delete your ~/.adobe directory, you can also see the splash screen in your original user account. But just as you said, after it disappears, the acroread does not start ...

Revision history for this message
Trent Lloyd (lathiat) wrote : Re: [Bug 2246] can not start acroread in breezy

On Sun, Oct 16, 2005 at 05:45:36PM -0000, zealubuntu wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/2246
>
> Comment:
> Tobias,
>
> I guess if you delete your ~/.adobe directory, you can also see the
> splash screen in your original user account. But just as you said, after
> it disappears, the acroread does not start ...

Can you upload an strace somewhere, example

strace -f acroread &> acroread-strace.log

then upload the acroread-strace.log file to some webspace, or attach it
to the bug.

Cheers,
Trent

--
Trent Lloyd <email address hidden>
Bur.st Networking Inc.

Revision history for this message
zealubuntu (zealubuntu) wrote : Re: can not start acroread in breezy
Revision history for this message
Trent Lloyd (lathiat) wrote :

Oh my bad, I'm blind. :)

Unfortunately as this is a binary package its quite difficult to see the problem :\

Revision history for this message
Tobias (mailinglists) wrote :

Do you want my strace as well, or is zealubuntu's file enough?

The problem is that it seems to work for some poeple and for others not. Maybe it works if you did not have acroread7 installed before upgrading to Breezy. Does this information help to solve this problem?

Revision history for this message
Ante Karamatić (ivoks) wrote :

YAY! I found the error. Could you guys please remove package:

scim-gtk2-immodule

and then try again. It seems that SCIM/UIM is very broken in Breezy. It crashes gnome-cups-add and acroread too.

Thank you.

Changed in scim:
assignee: nobody → motu
Revision history for this message
Tobias (mailinglists) wrote :

Wow, you are right. I removed scim-gtk2-immodule, and acroread works now!

However, doesn't this impair SCIM now? Sometimes I need to input asian signs -- do I have to expect problems with that now?

Thanks, Tobias.

Revision history for this message
zealubuntu (zealubuntu) wrote :

Confirmed. If scim-gtk2-immodule is removed, the acroread is working.

However, I still need to use SCIM frequently. Will there be a fix for scim-gtk2-immoudle or some work around?

Thanks.

Revision history for this message
In , Qian (qian-redhat-bugs) wrote :
Download full text (11.0 KiB)

Here is a valgrind output with gedit. The crash occurs when switching
to SCIM in the IM menu on Button3. This is with scim built configured with
--enable-ld-version-script. The scim version is 1.4.2-5, scim-pinyin version is
0.5.91-2.

-----------------------------------------------------------------
[root@localhost gedit]# valgrind --leak-check=yes gedit
==3529== Memcheck, a memory error detector.
==3529== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==3529== Using LibVEX rev 1367, a library for dynamic binary translation.
==3529== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==3529== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==3529== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==3529== For more details, rerun with: -v
==3529==
==3529== Syscall param write(buf) points to uninitialised byte(s)
==3529== at 0x1C461143: __write_nocancel (in /lib/libpthread-2.3.90.so)
==3529== by 0x1C5E420D: (within /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C5E442B: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C5C978A: (within /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C5C98A5: _XReply (in /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C5B5924: XInternAtom (in /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C5D2208: XSetWMProperties (in /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C25CA0B: (within /usr/lib/libgdk-x11-2.0.so.0.800.6)
==3529== by 0x1C25F59E: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.800.6
)
==3529== by 0x1C23F279: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.800
6)
==3529== by 0x1C220893: gdk_display_open_default_libgtk_only (in /usr/lib/lib
gdk-x11-2.0.so.0.800.6)
==3529== by 0x1C0124B6: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.800.6
)
==3529== Address 0x1CC8B470 is 128 bytes inside a block of size 16384 alloc'd
==3529== at 0x1B904AD4: calloc (vg_replace_malloc.c:279)
==3529== by 0x1C5B9D59: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==3529== by 0x1C23F19D: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.800
6)
==3529== by 0x1C220893: gdk_display_open_default_libgtk_only (in /usr/lib/lib
gdk-x11-2.0.so.0.800.6)
==3529== by 0x1C0124B6: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.800.6
)
==3529== by 0x1C0124E9: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.800.6)
==3529== by 0x1BAE0CDD: (within /usr/lib/libbonoboui-2.so.0.0.0)
==3529== by 0x1BB3B875: gnome_program_postinit (in
/usr/lib/libgnome-2.so.0.1200.0)
==3529== by 0x1BB3C216: (within /usr/lib/libgnome-2.so.0.1200.0)
==3529== by 0x1BB3C523: gnome_program_init (in
/usr/lib/libgnome-2.so.0.1200.0)
==3529== by 0x806096D: main (in /usr/bin/gedit)
==3529==
==3529== Syscall param write(buf) points to uninitialised byte(s)
==3529== at 0x1C461143: __write_nocancel (in /lib/libpthread-2.3.90.so)
==3529== by 0x1BA943A0: (within /usr/X11R6/lib/libICE.so.6.3)
==3529== by 0x1BA945B0: _IceTransWrite (in /usr/X11R6/lib/libICE.so.6.3)
==3529== by 0x1BA8D4C6: _IceWrite (in /usr/X11R6/lib/libICE.so.6.3)
==3529== by 0x1BA8D59F: IceFlush (in /usr/X11R6/lib/libICE.so.6.3)
==3529== by 0x1BA7E94F: SmcSetPropert...

Revision history for this message
In , Benjamin (benjamin-redhat-bugs) wrote :

Here's how I was told to reproduce.

Anyway it is pretty easy to reproduce:
1. checkout scim from package cvs, or we can provide you with
an srpm say if you prefer.
2. move the commented out "--enable-ld-version-script" to the %configure line.
3. build scim.
4. install built scim package.
5. install say scim-pinyin.
6. start a new desktop session in English locale say.
7. start gedit say.
8. button3 menu -> Input Method -> scim
9. watch gedit crash.

If you have any questions or if there is any way we can help
please don't hesitate to ask. :)

Jens

Revision history for this message
In , Benjamin (benjamin-redhat-bugs) wrote :

Created attachment 120441
force default visibility for mt_alloc pools

Revision history for this message
In , Qian (qian-redhat-bugs) wrote :

I use the patch above to rebuild gcc, then rebuid scim and scim-pinyin with
"--enable-ld-version-script", but gedit still crash.
The os version is rawhide 20051014, gcc package is from cvs in devel section.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

The above patch is not useful toward solving this problem. Benjamin later
determined that versioning weak symbols in libstdc++ is the proper and elegant
solution to solve this problem. Unfortunately it will take a while to implement.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660

Revision history for this message
Ming Hua (minghua) wrote :

Yes, removing scim-gtk2-immodule would eliminate the segfault. The reason is that scim-gtk2-immodule is the GTK IM module provided by scim, which links to libstdc++.so.6, while Acroread links to libstdc++.so.5.

See debian bug #323216 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323216) for details.

A workaround would be setting environment variable GTK_IM_MODULE to xim, and start scim manually. Use the following lines in your scim setting (if you've never written any scim setting and use GNOME, add them to your ~/.gnomerc):

export XMODIFIERS="@im=SCIM"
export GTK_IM_MODULE="xim"
scim -d

This is assuming bash shell.

Revision history for this message
zealubuntu (zealubuntu) wrote :

Yes, this workaround is OK for me. Thanks.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

To be clear, we really have two separate issues in FC4+ affecting us.

1) The above issue where we need versioning of weak symbols in libstdc++ to
solve. Benjamin describes this as an elegant solution to the problem and there
is strong confidence that this will work. It is only a matter of resource
allocation and schedules to work on it.
2) The crashing issue is due to the use of two different allocators. This will
be solved before FC5test2 with gcc-4.1 by reverting back to the previous
libstdc++ allocator used in RHEL4.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Right. (2) has been split out into bug 173220.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

NOTE: Please keep all communication regarding libstdc++7 private.

http://porkchop.redhat.com/beehive/comps/playpen/fc5/libstdc++so7/
First packaged attempt of libstdc++7. The -devel package includes the
libstdc++so7-g++ wrapper which you use instead of g++ if you want to build or
link a C++ application against this library.

I attempted to build scim and scim-anthy with this procedure:
1) export CXX=libstdc++so7-g++ before configure and make.
2) Remove --enable-ld-version-script

The end result had /usr/lib/gtk-2.0/immodules/im-scim.so still linked to
libstdc++.so.6 so I did something wrong. Further work is necessary in order to
complete this.

After scim and other scim plugins are fixed, Jakub said that special work must
be taken in order to build scim-qt because some parts of it links against
libstdc++.so.6 and the scim parts need libstdc++7. Here are some notes where he
describes what is necessary.

<jakub> warren: probably split the sources, so that there are some source files
that are using KDE/Qt headers (and those are compiled with g++)
<jakub> warren: then these files comunicate over a C API (well, it can be e.g.
some C++ classes, but they must never contain any STL stuff)
<jakub> warren: with other C++ files that use the SCIM headers and are compiled
with libstdc++so7-g++
<jakub> warren: finally, the link line will be slighly complicated, as you need
to link against both libstdc++'s
<jakub> warren: guess something like libstdc++so7-g++ ... -shared ... `g++
$CXXFLAGS -print-file-name=libstdc++.so`

Ming Hua (minghua)
Changed in scim:
status: Unconfirmed → Confirmed
Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

Status Update:
==============
libstdc++so7 package and scim have been tested, and are now ready. scim-qtimm
requires moderate hacking in order to work with the dual C++ ABI. scim-qtimm
can be fixed later because it is far less important.

libstdc++so7 is based on the libstdc++_7 C++ ABI which would be included in a
yet undecided gcc release. The libstdc++_7 ABI adds the needed "weak symbol
version" feature needed by this scim dual C++ requirement, in addition to other
C++ feature benefits. Benjamin Kosnik wants libstdc++so7 in FC5 in order to
satisfy the scim requirement and also expose libstdc++_7 to wide user testing.
Because libstdc++_7 is pre-alpha, we will guarantee in documentation and release
notes that the ABI and so-version (like libstdc++-20060125.so.7) will change in
future updates.

PackageListProcess has initiated and discussion currently ensues.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

libstdc++so7 has been included in dist-fc5 and scim updated and rebuilt against it.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

Bug #182177 has been filed to deal with the scim-qtimm NEEDSWORK issue.

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

I'd consider this to be done. Work continues in Bug #182117 for scim-qtimm and
elsewhere to possibly rewrite gtkimmodule in order to get rid of this
libstdc++so7 entire, but otherwise we're in good shape.

Ming Hua (minghua)
summary: + Having scim-gtk2-immodule installed and set GTK_IM_MODULE=scim, most
+ GTK+ applications that link to libstdc++.so.5 will likely to crash,
+ including mozilla/firefox/thunderbird from mozilla.org, Adobe Reader
+ (acroread) version 7, etc.
Revision history for this message
Matthias Klose (doko) wrote :

this works in dapper, workaround for breezy was provided.

Changed in scim:
assignee: motu → doko
status: Confirmed → Fix Released
Changed in acroread:
assignee: motu → doko
status: Unconfirmed → Fix Released
Revision history for this message
zero0w (zero0w) wrote :

More discussion on this topic can be found in the Ubuntu Wiki:

https://wiki.ubuntu.com/SCIM

Revision history for this message
Ming Hua (minghua) wrote :

I don't think this is fixed in dapper.

I'll test and write more details soon.

Revision history for this message
ZhengPeng Hou (zhengpeng-hou) wrote :

Maybe can use scim-bridge for a try , set GTK_IM_MODULE=scim-bridge .

Revision history for this message
firingstone (firingstone) wrote :

Same here Dapper has the problem with acroread
FYI I am using the debs (En version)from
ftp://ftp.nerim.net/debian-marillat/pool/main/a/acroread/
works but no CJK font support

Revision history for this message
firingstone (firingstone) wrote :

sudo gedit /usr/local/Adobe/Acrobat7.0/bin/acroread
and add
GTK_IM_MODULE=xim ; export GTK_IM_MODULE
this works for the chinese version now according to the solution for realplayer. but still need a fix for the bug

Revision history for this message
In , Warren (warren-redhat-bugs) wrote :

Update for Historical Purposes
==============================
Bug #185693 is where the gtkimmodule was rewritten in C with an abstraction over
a socket, thereby solving this C++ conflict problem. Thanks to Ryo Dairiki for
his great efforts in writing scim-bridge.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

*** Bug 217865 has been marked as a duplicate of this bug. ***

Revision history for this message
Ming Hua (minghua) wrote :

This bug is not fixed. Never has been, and not likely going to be fixed in the near future.

The real reason of this bug is that binaries compiled by g++ is exposing weak symbols that it's not supposed to expose. I heard that since the fix requires an ABI change in libstdc++, it won't get fixed until libstdc++7 is released. There are also many bugs reported in LP that is actually a duplicate of this bug, so please don't close it if there is only a workaround, but no real fix. (The GTK_IM_MODULE=xim fix in acroread is just a work around.)

I'll provide links to other distro's BTS on this bug soon, also marking other bugs reported in LP as a duplicate of this.

Changed in scim:
assignee: doko → nobody
status: Fix Released → Confirmed
Ming Hua (minghua)
description: updated
Revision history for this message
Ming Hua (minghua) wrote :

I've updated the bug description and added the work around.

I also added the links of the same issue in other distributions. There are even more information in the GCC upstream bugzilla and Debian BTS, but I don't know exactly how to add them in Launchpad. They are all listed in the Debian bug, though (323216), so if anyone want to know exactly what is going on, hopefully I've provided enough pointers. (I don't understand the detail of this problem myself.)

Changed in scim:
status: Unknown → Fix Released
Changed in scim:
status: Unknown → Unconfirmed
Revision history for this message
Rolf Leggewie (r0lf) wrote :

anybody still experiencing this problem?

Changed in scim (Ubuntu):
assignee: nobody → Rolf Leggewie (r0lf)
Revision history for this message
Rolf Leggewie (r0lf) wrote :

looks like this is fixed for everybody. Please reopen if you still experience this.

Changed in scim (Ubuntu):
status: Confirmed → Fix Released
Changed in scim (Debian):
status: New → Fix Released
Changed in scim (Fedora):
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.