Bug 97962

Created attachment 43056 [details]
konsole-backtrace

Only crashes if QT_IM_MODULE=scim

Created attachment 43057 [details]
konqueror-backtrace

Does not crash when QT_IM_MODULE is not set to "scim".

I found this on x86_64 but Stefan Dirsch <sndirsch@suse.de> can also reproduce this
on i386.

Is scim-qtimm cvs head version?

It is scim-qtimm-0.9.2.20050707, i.e. CVS HEAD from 20050707.

IMO, it's too old. Please update to the latest cvs head.

I'll try. Currently I cannot access the CVS of scim-qtimm though:

mfabian@magellan:/sakura/mfabian/suse-packages/STABLE/scim-qtimm/scim-qtimm-0.9.2.20050707$ cvs up -A
cvs [update aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused)
mfabian@magellan:/sakura/mfabian/suse-packages/STABLE/scim-qtimm/scim-qtimm-0.9.2.20050707$

Created attachment 43102 [details]
scim-qtimm cvs head.

Try this package. The pserver access of sf.net should be broken.

scim-qtimm 0.9.3 has been released, please upgrade.

I updated to scim-qtimm 0.9.3.

konsole and konqueror don't crash anymore.

*But* scim doesn't work! Typing the trigger key "Shift+Space" or "Control+Space"
just inserts a space. I tried this with the defaults on KDE, i.e. skim 1.4.0 was used.

Strange. It works correct on SLP 9.3.
Please rm -rf ~/.scim and try again.

Yes, exactly the same packages work fine for me on SuSE Linux 9.3 as well.

rm -rf ~/.scim won't help much, I tried a new installation of SuSE
Linux 10.0 x86_64 preview2 with test user, i.e. everything was default.

skim did crash after I clicked around a bit in the setup.

Then I tried scim without skim and it worked in xterm (XIM).

But:

   - it still didn't work in Qt applications
   - even in xterm only Control+Space worked, Shift+Space didn't although
     both are in the default setup as trigger keys
   - "mlterm --im=scim" didn't work either

It seems that it's caused by --enable-ld-version-script. Please disable it and
try again.

The build-log of the scim 1.4.0 package currently in STABLE contains:

    [...]
    Build options:
      Version                  1.4.0
      Install prefix           /usr
      Build shared libs        yes
      Build static libs        yes
      Build tests/*            no
      Enable debug             yes
      Enable ld version script no
    [...]

I.e. the ld version script is already disabled, isn't it?

It makes no difference whether I enable this option or not.

Input via QT_IM_MODULE=scim doesn't work on STABLE
no matter whtehr ld version script is enabled or not.

Strange. I could use scim-qtimm in Preview2 with a new compiled scim, but it's
not workable with the original scim package.

Could you please rebuild all scim package by hand and try again?

What do you mean by "by hand"?

You did built them on Preview2, didn't you? If you built them
on 9.3, it doesn't mean much that your hand-built package works.

I rebuilt scim and scim-qtimm on Preview2 without --enable-ld-version-script
option, which did work. But if I used --enable-ld-version-script, then all
applications got crashed. I don't know why.

I thought that the compile options might make a difference
and recompiled scim with

export CFLAGS="-g -O0 -fno-strict-aliasing"
export CXXFLAGS="-g -O0 -fno-strict-aliasing"

Usually the .spec file uses 

export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"
export CXXFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"

with

    RPM_OPT_FLAGS=-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2;

But that doesn't help for Qt applications, QT_IM_MODULE=scim still
doesn't work.

Did qt applications crash? Or just couldn't activate scim?

No, the Qt applications did not crash, I just couldn't activate scim?

All GTK2 applications did crash though when I logged in via "ssh -X"
from my machine (magellan, x86_64) to Stefan Dirsch's machine
(shannon, i386) and started GTK2 applications there. They did not
crash with GTK_IM_MODULE=xim and they did not crash when Stefan
started them locally on shannon. And they do not crash when I start
the same applications locally on magellan. When started locally, scim
works fine with those applications. Both machines are running STABLE
around Preview2. I'll check that effect again tomorrow, it is weird
that it happens only when logging in remotely.

When I log in remotely to shannon via "ssh -X", the following
command line of scim-launcher crashes:

mfabian@shannon:~$ /usr/lib/scim-1.0/scim-launcher -d -c simple -e all -f socket --no
-stay -v -v -v -m all
Loading simple Config module ...
Creating backend ...
Segmentation fault (core dumped)
mfabian@shannon:~$

It crashes only if the pinyin engine is loaded:

mfabian@shannon:~$ /usr/lib/scim-1.0/scim-launcher -d -c simple -e pinyin -f socket --no-stay -v -v -v -m all
Loading simple Config module ...
Creating backend ...
Segmentation fault (core dumped)
mfabian@shannon:~$

mfabian@shannon:~$ /usr/lib/scim-1.0/scim-launcher -d -c simple -ne pinyin -f socket
--no-stay -v -v -v -m all
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
mfabian@shannon:~$

Backtrace looks like this:

(gdb) bt
#0  0x438a6158 in ?? () from /usr/lib/scim-1.0/IMEngine/pinyin.so
#1  0x438af496 in PinyinFactory::PinyinFactory ()
   from /usr/lib/scim-1.0/IMEngine/pinyin.so
#2  0x438af778 in pinyin_LTX_scim_imengine_module_create_factory ()
   from /usr/lib/scim-1.0/IMEngine/pinyin.so
#3  0x400a34f0 in scim::IMEngineModule::create_factory (this=0x807ee3c, engine=0)
    at scim_imengine_module.cpp:98
#4  0x40072e31 in CommonBackEnd (this=0x8060468, config=@0x804b280, modules=@0x1)
    at scim_backend.cpp:434
#5  0x08049585 in main (argc=14, argv=0xbfabc244) at scim_launcher.cpp:200
#6  0x40253e60 in __libc_start_main (main=0x8049390 <main>, argc=14,
    ubp_av=0xbfabc244, init=0x804a790 <__libc_csu_init>,
    fini=0x804a800 <__libc_csu_fini>, rtld_fini=0x4000bdf0 <_dl_fini>,
    stack_end=0xbfabc23c) at libc-start.c:209
#7  0x08049201 in _start () at start.S:119
(gdb)

It also crashes with the "uim" engine:

mfabian@shannon:~$ /usr/lib/scim-1.0/scim-launcher -d -c simple -e uim -f socket --no
-stay -v -v -v -m all
Loading simple Config module ...
Creating backend ...
セグメンテーション違反です (core dumped)
mfabian@shannon:~$

I found that in Preview3, scim was totally broken, no matter the official rpms
or built from source packages manually. But the crash point made completely no
sense. 

Is it possible that g++ is broken? Because I couldn't reproduce such issue even
in Snapshot2.

Oh, I found that if both scim and scim-pinyin were compiled with "-O0 -g" flags,
then command "/usr/lib/scim-1.0/scim-launcher -f socket -e pinyin" won't crash
anymore.

It seems that g++ is really broken :-(

Zhe Su> But the crash point made completely no sense.

I also tried to debug this yesterday with gdb and it could not
understand what happens either. Maybe your are right and
there is a problem with g++? I'll try to ask Michael Matz.

I can reproduce that it works when scim and scim-pinyin are both
compiled with "-g -O0".

That doesn't help for scim-uim though, even when both scim and scim-uim
are compiled with "-g -O0", it still crashes:

mfabian@baker:~$ /usr/lib/scim-1.0/scim-launcher -f socket -e uim
Loading simple Config module ...
Creating backend ...
セグメンテーション違反です (core dumped)
mfabian@baker:~$

I do think there is some thing wrong in our compiler. 

Is there any progress? I'd really like to see this bug would be fixed in beta1.

Yes, right now I'm trying out a fix suggested by Michael Matz.

Results in 30 minutes ...

Yes, adding the configure option

    --enable-debug

to the scim-uim.spec file fixed the crash mentioned in comment #28.

I'll add the --enable-debug to all scim-* packages now
because this seems to be the quickest fix for Beta1.

In the long run, we should think how scim_debug.cpp and scim_debug.h
could be improved.

Currently is necessary to use "--enable-debug" either always
or never. If scim itself is compiled with "--enable-debug" and
a engine like scim-uim is compiled without crashes can happen.

I added the "--enable-debug" configure option to all scim-* packages
which didn't yet have it and submitted them to STABLE.

Please test scim cvs head to see whether this bug has been fixed.

Yes, I will test CVS HEAD as soon as possible to check whether this
problem has been fixed. I saw the checkin on the scim-cvs mailing list
and your change looks plausible, it might fix the problem.

But first there are some more urgent problems, although I added the
--enable-debug option to all scim related packages now, the following
problems remain on Preview 4 x86_64 with the updated scim packages:

    - skim still crashes
    - After deleting the skim package and restarting the KDE session
      I cannot activate scim with the trigger keys. Neither for
      Qt nor for GTK2 applications. And not for applications using XIM
      either.

I did not yet test this on i386.

After recompiling and installing scim cvs head and scim-qtimm 0.9.3 on Preview3,
all thinks work correct. skim doesn't crash, scim could be activated in all
applications as well.

Other module packages are original ones shipped in Preview3.

On i386 I guess? I tried only on x86_64. Maybe it is different on i386.

scim activation issue exists on i386 platform as well. But it disappeared after
I reinstalled scim and scim-qtimm from source code.

Apparently it works fine on SuSE Linux 10.0 Beta2, i.e. we
can close this bug as FIXED.