scim-anthy does not work and make any application which uses it hang

[David Cournapeau]

I've just upgraded a machine from edgy to feisty, and I have problems with the input system, which worked perfectly before. My system is the following:
- I am using scim as the input system
- GTK_IM_MODULE is set to scim
- XMODIFIERS set to @im=scim
- scim -d is launched by the session manager.

The problem is that whenever I try to input Japanese using scim-anty, all GUI hangs when I want to convert from kana to Kanji. For example, let's say I want to input 日本: after inputing にほん， pressing the space to convert to 日本 make the application unresponsive. In some cases, the GUI comes back after some time, but it often crashes other applications (the gnome terminal is one such example). I could reproduce this behaviour on my laptop, which also run on feisty.

[Ming Hua (minghua)]

> - XMODIFIERS set to @im=scim

It may not be related to the bug, but this setting is incorrect. The correct setting for XMODIFIERS is @im=SCIM, uppercase. However with GTK_IM_MODULE set to scim, this environment variable shouldn't have any effect.

Would you please set GTK_IM_MODULE to xim and test again? Thanks.

[David Cournapeau (david-ar)]

Ming Hua wrote:
>> - XMODIFIERS set to @im=scim
>
> It may not be related to the bug, but this setting is incorrect. The
> correct setting for XMODIFIERS is @im=SCIM, uppercase. However with
> GTK_IM_MODULE set to scim, this environment variable shouldn't have any
> effect.
>
> Would you please set GTK_IM_MODULE to xim and test again? Thanks.
>
Sorry for the late reply.　It looks like there are two specific
problemes, actually: applications hanging up when scim is the IM, and
problems when converting from kana to kanji, specific to scim-anthy.

First, I removed all the settings related to IM from my .xsession and my
bashrc, to test it on a per application basis. When I do:

GTK_IM_MODULE=xim mozilla-thunderbird

then it launches correctly. If I replace xim by scim in the above
command, it does not work anymore. scim is effectively launched, since I
get:

Launching a SCIM daemon with Socket FrontEnd...
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
GTK Panel of SCIM 1.4.4

But it hangs here, apparently doing nothing (no cpu is taken by the
process). This is the same whatever application using gtk I launch.
Something which may be of some interest is that when I launches an
application with GTK_IM_MODULE set to scim under strace, it always hangs
at the following call:

connect(3, {sa_family=AF_FILE, path="/tmp/scim-socket-frontend-david"},

Sometimes, it does launch, but when I try to input some japanese, it
hangs up again (on the same call if I run the application under strace).
I don't know if this is related, but as this cause many problems for
other softwares: I have my home on a NFS share,

Cheers,

David

[Ming Hua (minghua)]

On Mon, May 14, 2007 at 02:23:39AM -0000, David Cournapeau wrote:
>
> Sorry for the late reply.　It looks like there are two specific
> problemes, actually: applications hanging up when scim is the IM, and
> problems when converting from kana to kanji, specific to scim-anthy.
>
> First, I removed all the settings related to IM from my .xsession and my
> bashrc, to test it on a per application basis. When I do:
>
> GTK_IM_MODULE=xim mozilla-thunderbird
>
> then it launches correctly. If I replace xim by scim in the above
> command, it does not work anymore. scim is effectively launched,
> since I get:
>
> Launching a SCIM daemon with Socket FrontEnd...
> Loading simple Config module ...
> Creating backend ...
> Loading socket FrontEnd module ...
> Starting SCIM as daemon ...
> GTK Panel of SCIM 1.4.4
>
> But it hangs here, apparently doing nothing (no cpu is taken by the
> process). This is the same whatever application using gtk I launch.
> Something which may be of some interest is that when I launches an
> application with GTK_IM_MODULE set to scim under strace, it always hangs
> at the following call:
>
> connect(3, {sa_family=AF_FILE, path="/tmp/scim-socket-frontend-david"},

I am confused here. There is a known bug about GTK_IM_MODULE=scim not
working, related to old C++ library libstdc++5, reported as bug #2246.
But this doesn't seem to be the case here.

> I don't know if this is related, but as this cause many problems for
> other softwares: I have my home on a NFS share,

Maybe, but I have too little experience on NFS to have any informed
opinion. But as we are talking about this, your /tmp is on a local
disk, isn't it?

Ming
2007.05.15

[David Cournapeau (david-ar)]

Ming Hua wrote:
> On Mon, May 14, 2007 at 02:23:39AM -0000, David Cournapeau wrote:
>> Sorry for the late reply.　It looks like there are two specific
>> problemes, actually: applications hanging up when scim is the IM, and
>> problems when converting from kana to kanji, specific to scim-anthy.
>>
>> First, I removed all the settings related to IM from my .xsession and my
>> bashrc, to test it on a per application basis. When I do:
>>
>> GTK_IM_MODULE=xim mozilla-thunderbird
>>
>> then it launches correctly. If I replace xim by scim in the above
>> command, it does not work anymore. scim is effectively launched,
>> since I get:
>>
>> Launching a SCIM daemon with Socket FrontEnd...
>> Loading simple Config module ...
>> Creating backend ...
>> Loading socket FrontEnd module ...
>> Starting SCIM as daemon ...
>> GTK Panel of SCIM 1.4.4
>>
>> But it hangs here, apparently doing nothing (no cpu is taken by the
>> process). This is the same whatever application using gtk I launch.
>> Something which may be of some interest is that when I launches an
>> application with GTK_IM_MODULE set to scim under strace, it always hangs
>> at the following call:
>>
>> connect(3, {sa_family=AF_FILE, path="/tmp/scim-socket-frontend-david"},
>
> I am confused here. There is a known bug about GTK_IM_MODULE=scim not
> working, related to old C++ library libstdc++5, reported as bug #2246.
> But this doesn't seem to be the case here.
This does not seem related at all. First, scim is linked to libstdc++6,
and this problem appears for any gtk applications, even the ones which
do not use c++ (for example gedit does not seem to be linked to
libstdc++ according to ldd).
>
> Maybe, but I have too little experience on NFS to have any informed
> opinion. But as we are talking about this, your /tmp is on a local
> disk, isn't it?
Yes, only $HOME is on NFS. To be sure that the problem is not coming
from nfs, I put $HOME/.scim on my local dist through a soft link, but
maybe other directories in $HOME are involved, dunno.

Basically, I think this is a bug related to connecting to the socket. If
I "start fresh", that is I unset GTK_IM_MODULE (and XMODIFIERS and
XIM_INPUT) and do not automatically launch scim in my session, I then do
the following:
    - start scim manually in a terminal (with scim -d)
    - in the same terminal, I launch an application this way:
GTK_IM_MODULE=scim strace app

Any application hangs at the following call:

connect(17, {sa_family=AF_FILE, path="/tmp/scim-socket-frontend-david"},
33) = 0

After sometimes (around one minute, generally), the application
continues, but then the problem appears again when I want to use the
kanji configuration (at the same system call). After again sometimes,
the app continues, but without the kanji configuration.

Besides $HOME on NFS, the other thing which is really peticular in my
setup, and maybe related, is that I do not have any DNS server on my
network. All connection are done through a proxy (I have http_proxy set
to the proxy). Again, not sure it is related, but it also has been the
cause of problems with other softwares,

At this point, I am ready to use a debugging version of scim :...

[Ming Hua (minghua)]

Hi David,

I need a clarification about the situation -- does XIM mode work for you? To test, modify you .xsession (as you seem to be using .xsession) to add:

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

And then restart X. Now in GTK apps such as gedit, you should see "X Input Method" selected in the right-click menu. Now if scim still doesn't work, we can continue to investigate the socket issue.

As for the debug package, sorry scim still doesn't provide a debug symbol package yet. I'd like to give you a package to test with debug symbol included (maybe also a new upstream version), but let's clarify some things first.

[Ming Hua (minghua)]

Also, if you want to investigate the socket issue yourself, there is a --no-socket option available (read the scim(1) man page), which may be helpful. Note that IIRC only XIM mode works with --no-socket though, as the GTK IM module must use the socket modules.

[David Cournapeau (david-ar)]

Ming Hua wrote:
> Hi David,
>
> I need a clarification about the situation -- does XIM mode work for
> you? To test, modify you .xsession (as you seem to be using .xsession)
> to add:
>
> XMODIFIERS="@im=SCIM"
> GTK_IM_MODULE="xim"
> export XMODIFIERS
> export GTK_IM_MODULE
> scim -d
>
> And then restart X. Now in GTK apps such as gedit, you should see "X
> Input Method" selected in the right-click menu. Now if scim still
> doesn't work, we can continue to investigate the socket issue.
I did that, except that I set the env variables in a terminal (I removed
my .xsession file first, of course), and it does what it is supposed to
do (that is if I choose the input system, xim is set as a default). Note
that I still somtimes problems with software (they launch but hang; it
hangs at a different system call, though, according to strace for the
launched application).

Anyway, when I want to use japanese input (anthy system), it still fails
when I try to convert the kana to kanji.

I have to confess though I am a bit confused: what does it mean to set
XMODIFIERS to SCIM, but GTK_IM_MODULE to xim ? What is the connection
between scim and xim ? (I thought scim was a "better" xim, eg they
provide the same functionality).
>
> As for the debug package, sorry scim still doesn't provide a debug
> symbol package yet. I'd like to give you a package to test with debug
> symbol included (maybe also a new upstream version), but let's clarify
> some things first.
I tried to install it by myself from sources, but there seems to be a
bug in they autoconf/automake scripts which prevents me from installing
it in my $HOME (I do not have root access to this machine).

David

[Ming Hua (minghua)]

On Sun, May 20, 2007 at 06:47:03AM -0000, David Cournapeau wrote:
> Ming Hua wrote:
> > Hi David,
> >
> > I need a clarification about the situation -- does XIM mode work for
> > you? To test, modify you .xsession (as you seem to be using .xsession)
> > to add:
> >
> > XMODIFIERS="@im=SCIM"
> > GTK_IM_MODULE="xim"
> > export XMODIFIERS
> > export GTK_IM_MODULE
> > scim -d
> >
> > And then restart X. Now in GTK apps such as gedit, you should see "X
> > Input Method" selected in the right-click menu. Now if scim still
> > doesn't work, we can continue to investigate the socket issue.
>
> I did that, except that I set the env variables in a terminal (I removed
> my .xsession file first, of course), and it does what it is supposed to
> do (that is if I choose the input system, xim is set as a default). Note
> that I still somtimes problems with software (they launch but hang; it
> hangs at a different system call, though, according to strace for the
> launched application).

Thanks.

> Anyway, when I want to use japanese input (anthy system), it still fails
> when I try to convert the kana to kanji.

If it still looks like a problem with socket, you can try changing the
above "scim -d" command to "scim -f x11 --no-socket -d" and see if it
helps anything.

> I have to confess though I am a bit confused: what does it mean to set
> XMODIFIERS to SCIM, but GTK_IM_MODULE to xim ? What is the connection
> between scim and xim ? (I thought scim was a "better" xim, eg they
> provide the same functionality).

To put it short: SCIM is not a better XIM, it's a layer above XIM and
uses XIM. It is also able to not use XIM and use GTK IM instead, and
GTK IM is supposed to be a "better" XIM.

I have written some more detailed doc in /usr/share/doc/scim/README.GTK,
so if you are interested you can read it. You may also want to read
other README docs in that directory. Note it's written for Debian,
though, so some information may not apply to Ubuntu.

> > As for the debug package, sorry scim still doesn't provide a debug
> > symbol package yet. I'd like to give you a package to test with debug
> > symbol included (maybe also a new upstream version), but let's clarify
> > some things first.
>
> I tried to install it by myself from sources, but there seems to be a
> bug in they autoconf/automake scripts which prevents me from installing
> it in my $HOME (I do not have root access to this machine).

Yeah, installing scim without root privilege is a quite tricky thing.
The main problem is the GTK IM module, and some one has sent a patch to
the upstream [1], you may want to have a look. It modifies configure.ac
though, so you need to regenerate all the autotools stuff if you want to
apply it.

1. http://www.nabble.com/Changing-gtk2-im-module-install-dir-tf3675313s16577.html

Ming
2007.05.20

[David Cournapeau (david-ar)]

Ming Hua wrote:
>
> If it still looks like a problem with socket, you can try changing the
> above "scim -d" command to "scim -f x11 --no-socket -d" and see if it
> helps anything.
I still have softwares hanging, but the kanji convertion does work. But
kana to kanji convertion can takes up to several minutes (does not take
CPU, though), so this is still pretty unusable :)
>
> To put it short: SCIM is not a better XIM, it's a layer above XIM and
> uses XIM. It is also able to not use XIM and use GTK IM instead, and
> GTK IM is supposed to be a "better" XIM.
>
> I have written some more detailed doc in /usr/share/doc/scim/README.GTK,
> so if you are interested you can read it. You may also want to read
> other README docs in that directory. Note it's written for Debian,
> though, so some information may not apply to Ubuntu.
Thanks for the clarification. All this stuff seemed pretty complicated
to me first when I started using non western input :)
>
> Yeah, installing scim without root privilege is a quite tricky thing.
> The main problem is the GTK IM module, and some one has sent a patch to
> the upstream [1], you may want to have a look. It modifies configure.ac
> though, so you need to regenerate all the autotools stuff if you want to
> apply it.
>
> 1. http://www.nabble.com/Changing-gtk2-im-module-install-dir-
> tf3675313s16577.html
>
Ok, the patch applied, with some hunk. I could compile and install scim
(1.4.6) with debug symbols, and the problem of launching applications
using scim above xim seems to disappear (no hanging for now).

But I don't know how to install anthy on it so that I can try Japanese
input (I installed scim-anthy, but I guess this is not enought to make
scim look for plugins...)

David

[Ming Hua (minghua)]

On Wed, May 23, 2007 at 01:36:53AM -0000, David Cournapeau wrote:
> Ming Hua wrote:
> >
> > If it still looks like a problem with socket, you can try changing the
> > above "scim -d" command to "scim -f x11 --no-socket -d" and see if it
> > helps anything.
>
> I still have softwares hanging, but the kanji convertion does work. But
> kana to kanji convertion can takes up to several minutes (does not take
> CPU, though), so this is still pretty unusable :)

Okay, thanks for testing. I am afraid I don't have enough time to
follow this through and hopefully someone else can step up and help
diagnose this.

> But I don't know how to install anthy on it so that I can try Japanese
> input (I installed scim-anthy, but I guess this is not enought to make
> scim look for plugins...)

If you can get the admin to install packages for you, you probably don't
need to install new anthy. Maybe the first thing to try is recompile
scim-anthy against your new local scim and see if that helps. You need
to have your admin install the build dependency of scim-anthy, though
(with the exception of libscim-dev, which you don't need with the local
scim).

Ming
2007.05.26

[Minase (spam-encapsulated)]

I just thought I'd chime in to say I am having this same issue with Feisty, which never exhibited itself in the previous two versions of Ubuntu I have used.

So far, this bug *only* affects gnome-terminal for me - though I don't type much Japanese in other applications, so who knows.
When it does affect gnome-terminal, most of the time it results in a crash after a second or two, which spits out the following to the console:

---
*** glibc detected *** gnome-terminal: munmap_chunk(): invalid pointer: 0x08865120 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7533f5b]
/usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb7738131]
/usr/lib/libglib-2.0.so.0[0xb774d14a]
/usr/lib/libglib-2.0.so.0(g_string_append_printf+0x17)[0xb774d167]
/usr/lib/libglib-2.0.so.0(g_log_default_handler+0x3b9)[0xb773a3d9]
/usr/lib/libglib-2.0.so.0(g_logv+0x2e5)[0xb7739525]
/usr/lib/libglib-2.0.so.0(g_log+0x29)[0xb7739749]
/usr/lib/libvte.so.9[0xb7d7b0e9]
/usr/lib/libvte.so.9[0xb7d7c9ca]
/usr/lib/libvte.so.9[0xb7d6e0ee]
/usr/lib/libvte.so.9[0xb7d5deb4]
/usr/lib/libvte.so.9[0xb7d67076]
/usr/lib/libgtk-x11-2.0.so.0(_gtk_marshal_BOOLEAN__BOXED+0x60)[0xb7b2a6b0]
/usr/lib/libgobject-2.0.so.0[0xb77a0e49]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb77a262b]
/usr/lib/libgobject-2.0.so.0[0xb77b3753]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0xb77b43ef]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb77b47e9]
/usr/lib/libgtk-x11-2.0.so.0[0xb7c3ee18]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x534)[0xb7b24de4]
/usr/lib/libgdk-x11-2.0.so.0[0xb799064f]
/usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x97)[0xb7990887]
/usr/lib/libgdk-x11-2.0.so.0[0xb7990905]
/usr/lib/libglib-2.0.so.0[0xb772f091]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0xb7730df2]
/usr/lib/libglib-2.0.so.0[0xb7733dcf]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb7734179]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0xb7b25044]
gnome-terminal(main+0x754)[0x8064374]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb74deebc]
gnome-terminal[0x8059471]
======= Memory map: ========
08048000-0808e000 r-xp 00000000 08:02 39991 /usr/bin/gnome-terminal
0808e000-08090000 rw-p 00046000 08:02 39991 /usr/bin/gnome-terminal
08090000-08a6a000 rw-p 08090000 00:00 0 [heap]
aee78000-aff95000 r--p 00000000 08:02 69837 /usr/local/share/fonts/ukai.ttf
aff95000-b17d9000 r--p 00000000 08:02 69881 /usr/local/share/fonts/uming.ttf
b17d9000-b2e0c000 r--p 00000000 08:02 11910 /usr/local/share/fonts/ARIALUNI.TTF
b314c000-b314d000 ---p b314c000 00:00 0
b314d000-b394d000 rw-p b314d000 00:00 0
b394d000-b39ca000 r--p 00000000 08:02 809 /usr/lib/locale/ja_JP.utf8/LC_CTYPE
b39ca000-b39dc000 r-xp 00000000 08:02 19210 /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
b39dc000-b39dd000 rw-p 00011000 08:02 19210 /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
b39dd000-b3a18000 r--p 00000000 08:02 25511 /usr/lib/locale/en_US.utf8/LC_CTYPE
b3a18000-b3af7000 r-xp 00000000 08:02 39725 /usr/lib/libstdc++.so.6.0.8
b3af7000-b3afa000 r--p 000de000 08:02 39725 /usr/lib/libstdc++.so.6.0.8
b3afa000-b3afc000 rw-p 000e...

[David Cournapeau (david-ar)]

Minase wrote:
> I just thought I'd chime in to say I am having this same issue with
> Feisty, which never exhibited itself in the previous two versions of
> Ubuntu I have used.
>
> So far, this bug *only* affects gnome-terminal for me - though I don't type much Japanese in other applications, so who knows.
> When it does affect gnome-terminal, most of the time it results in a crash after a second or two, which spits out the following to the console:
>
> ---
> *** glibc detected *** gnome-terminal: munmap_chunk(): invalid pointer: 0x08865120 ***
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7533f5b]
> /usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb7738131]
> /usr/lib/libglib-2.0.so.0[0xb774d14a]
> /usr/lib/libglib-2.0.so.0(g_string_append_printf+0x17)[0xb774d167]
> /usr/lib/libglib-2.0.so.0(g_log_default_handler+0x3b9)[0xb773a3d9]
> /usr/lib/libglib-2.0.so.0(g_logv+0x2e5)[0xb7739525]
> /usr/lib/libglib-2.0.so.0(g_log+0x29)[0xb7739749]
> /usr/lib/libvte.so.9[0xb7d7b0e9]
> /usr/lib/libvte.so.9[0xb7d7c9ca]
> /usr/lib/libvte.so.9[0xb7d6e0ee]
> /usr/lib/libvte.so.9[0xb7d5deb4]
> /usr/lib/libvte.so.9[0xb7d67076]
> /usr/lib/libgtk-x11-2.0.so.0(_gtk_marshal_BOOLEAN__BOXED+0x60)[0xb7b2a6b0]
> /usr/lib/libgobject-2.0.so.0[0xb77a0e49]
> /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb77a262b]
> /usr/lib/libgobject-2.0.so.0[0xb77b3753]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0xb77b43ef]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb77b47e9]
> /usr/lib/libgtk-x11-2.0.so.0[0xb7c3ee18]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x534)[0xb7b24de4]
> /usr/lib/libgdk-x11-2.0.so.0[0xb799064f]
> /usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x97)[0xb7990887]
> /usr/lib/libgdk-x11-2.0.so.0[0xb7990905]
> /usr/lib/libglib-2.0.so.0[0xb772f091]
> /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0xb7730df2]
> /usr/lib/libglib-2.0.so.0[0xb7733dcf]
> /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb7734179]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0xb7b25044]
> gnome-terminal(main+0x754)[0x8064374]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb74deebc]
> gnome-terminal[0x8059471]
> ======= Memory map: ========
> 08048000-0808e000 r-xp 00000000 08:02 39991 /usr/bin/gnome-terminal
> 0808e000-08090000 rw-p 00046000 08:02 39991 /usr/bin/gnome-terminal
> 08090000-08a6a000 rw-p 08090000 00:00 0 [heap]
> aee78000-aff95000 r--p 00000000 08:02 69837 /usr/local/share/fonts/ukai.ttf
> aff95000-b17d9000 r--p 00000000 08:02 69881 /usr/local/share/fonts/uming.ttf
> b17d9000-b2e0c000 r--p 00000000 08:02 11910 /usr/local/share/fonts/ARIALUNI.TTF
> b314c000-b314d000 ---p b314c000 00:00 0
> b314d000-b394d000 rw-p b314d000 00:00 0
> b394d000-b39ca000 r--p 00000000 08:02 809 /usr/lib/locale/ja_JP.utf8/LC_CTYPE
> b39ca000-b39dc000 r-xp 00000000 08:02 19210 /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
> b39dc000-b39dd000 rw-p 00011000 08:02 19210 /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
> b39dd000-b3a18000 r--p 00000000 08:02 25511 /usr/lib/locale/en_US.utf8/LC_CTYPE
> b3a18000-b3af7000 r-xp 00000000 08:02 39725 /usr/lib/l...

[Ming Hua (minghua)]

On Mon, Jun 04, 2007 at 01:47:03AM -0000, David Cournapeau wrote:
> Minase wrote:
> >
> > Interestingly, I am also using an NFS home... though I can't see why
> > this could be related.
> >
> I think this is really related because the bug seems to happen, at least
> in my case, with the fnctl system call (file locking), which has
> different semantics on nfs than on local fs (nfs 2 and 3 do not support
> file loking through the call at all, I think, but I know nothing about
> nfs internals...)

I don't know much about scim internals, but I doubt it does locking in
the home directory (the only files it access should be ~/.scim/global
and ~/.scim/config).

I am starting to wonder if this is a bug in anthy instead of scim.
Maybe you guys can test scim-prime/scim-skk/scim-canna/scim-tables-ja
and see if the same bug happens?

Ming
2007.06.08

[David Cournapeau (david-ar)]

Ming Hua wrote:
> On Mon, Jun 04, 2007 at 01:47:03AM -0000, David Cournapeau wrote:
>> Minase wrote:
>>> Interestingly, I am also using an NFS home... though I can't see why
>>> this could be related.
>>>
>> I think this is really related because the bug seems to happen, at least
>> in my case, with the fnctl system call (file locking), which has
>> different semantics on nfs than on local fs (nfs 2 and 3 do not support
>> file loking through the call at all, I think, but I know nothing about
>> nfs internals...)
>
> I don't know much about scim internals, but I doubt it does locking in
> the home directory (the only files it access should be ~/.scim/global
> and ~/.scim/config).
>
> I am starting to wonder if this is a bug in anthy instead of scim.
> Maybe you guys can test scim-prime/scim-skk/scim-canna/scim-tables-ja
> and see if the same bug happens?
At least in my case, it showed similar buggy behaviour for any plugin I
threw at scim, including scim-tables-ja, scim-canna, etc... and at the
exact same function call (see my initial bug report).

cheers,

David

[Ming Hua (minghua)]

On Fri, Jun 08, 2007 at 06:20:32AM -0000, David Cournapeau wrote:
> Ming Hua wrote:
> >
> > I am starting to wonder if this is a bug in anthy instead of scim.
> > Maybe you guys can test scim-prime/scim-skk/scim-canna/scim-tables-ja
> > and see if the same bug happens?
>
> At least in my case, it showed similar buggy behaviour for any plugin I
> threw at scim, including scim-tables-ja, scim-canna, etc... and at the
> exact same function call (see my initial bug report).

I see. In that case this bug probably should be reassigned to scim from
scim-anthy. It's not likely to help solving this bug though, so I'll
wait until I see any duplicates.

Ming
2007.06.08

[Minase (spam-encapsulated)]

Just another note in addition to my above:

When the app crashes within a second or two, yes, you get the output I pasted above.
Today, it's simply been hanging indefinitely a *lot* (seems to change with the weather :)), and when it does so, I merely get this:

*** glibc detected *** gnome-terminal: double free or corruption (!prev): 0x084ce6c8 ***

Later, I'll try with another scim module and see what happens. Unfortunately I don't know Chinese or anything though, so hopefully random button pressing will be enough... :)

[Minase (spam-encapsulated)]

A few more things to say...

I'm not entirely sure me and David are seeing the same bug anymore, but I now know a way to reliably reproduce mine at least: in gnome-terminal, simply type a huge list of kana you wouldn't do normally, so your pre-edit string is 20-30 or so chars long. For example, just hold a key down.

The wierd thing here, is that so far I've witnessed it crash in 4 different ways. I think we may be looking at some kind of memory corruption that is affecting later behavior unpredictably... :\

These range from segfaults, hanging (with the glibc corruption detected messages) on 'futex(0xb7640120, FUTEX_WAIT, 2, NULL' in strace, catching SIGALRM from somewhere, etc...

How do I get copies of the relevant binaries with debugging symbols in? My GDB-foo is weak, but I could try and poke around.
Is there anything else I can do to help? I'd really like this to be fixed as soon as possible, and I'm probably capable of whatever investigative work needs to be done to get this bug elevated in status - I just know nothing of SCIM/gnome/etc internals.

Off to log in/out now and see if I can reproduce this with scim-hangul...

[Minase (spam-encapsulated)]

Triple posting... perhaps I should have prepared all this beforehand :)

Tried scim-hangul. The bug I am seeing can seemingly be reproduced here also, by selecting '3bul Yetgul', and err... mashing the keys until it hangs or crashes.
A *lot* harder to reproduce than in anthy though - I'm guessing since the pre-edit string never gets longer than two or three chars.

Tried it in scim-pinyin (in a number of modes), and can't reproduce no matter what I do.

[Ming Hua (minghua)]

On Fri, Jun 08, 2007 at 09:38:51PM -0000, Minase wrote:
>
> Tried it in scim-pinyin (in a number of modes), and can't reproduce no
> matter what I do.

Which probably explains why I've never seen such bugs in Debian -- I
only use scim-pinyin regularly, and don't use scim-anthy at all. I do
check scim-tables-zh, scim-uim, scim-hangul, and scim-m17n occasionally,
but never encountered such problems either.

Minase, if you are willing to test different SCIM modules, you probably
want to try scim-canna/scim-prime/scim-skk/scim-tables-ja first, as they
are also Japanese input methods.

Ming
2007.06.10

[Minase (spam-encapsulated)]

Fixed now in Gutsy. Did an upgrade and kept all my previous settings, and can no longer make it hang no matter how hard I try :)

[Daniel T Chen (crimsun)]

David, is this symptom still reproducible in 8.10 beta?

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.