Debian Bug report logs - #377808
uim crashing depends on .xinput.d

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: uim can cause crash of X

Date: Tue, 11 Jul 2006 14:11:42 +0200

Package: uim
Version: 1:1.1.0-1.2 (also earlier versions)
Severity: important


See bug 366390. When uim is running (in 'direct' input mode) mis-hitting
keys causes Mozilla and Firefox to crash, freezing the entire X. Fortunately
X still responds to control-alt-Fn, so it is possible to go to a VT and kill
Mozilla/Firefox.

Mozilla/Firefox do not do this when uim is not running. 

Regards, Jan

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages uim depends on:
ii  uim-common                   1:1.1.0-1.2 Common files for uim
ii  uim-fep                      1:1.1.0-1.2 uim Front End Processor
ii  uim-gtk2.0                   1:1.1.0-1.2 GTK+2.x immodule for uim
ii  uim-utils                    1:1.1.0-1.2 Utilities for uim
ii  uim-xim                      1:1.1.0-1.2 A bridge between uim and XIM

uim recommends no packages.

-- debconf-show failed

Message #10 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Masahito Omote" <omote@debian.org>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>, 377808@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#377808: uim can cause crash of X

Date: Tue, 11 Jul 2006 22:30:15 +0900

tags 377808 moreinfo
tags 377808 unreproducible
severity 377808 normal
thanks

2006/7/11, Jan Willem Stumpel <jstumpel@planet.nl>:
> Mozilla/Firefox do not do this when uim is not running.

Probably this bug comes from uim. But I cannot reproduce.

> See bug 366390. When uim is running (in 'direct' input mode) mis-hitting
> keys causes Mozilla and Firefox to crash, freezing the entire X. Fortunately
> X still responds to control-alt-Fn, so it is possible to go to a VT and kill
> Mozilla/Firefox.

First, list up your environment variables. I cannot find out which
method - XIM or
GTK+ immodule you are using? If possible give me a strace outputs from VT.
(Fx/Mozilla process and uim-xim process)

thanks,

Masahito Omote(omote@debian.org)

Message #21 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: Masahito Omote <omote@debian.org>

Cc: Jan Willem Stumpel <jstumpel@planet.nl>, 377808@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#377808: uim can cause crash of X

Date: Tue, 11 Jul 2006 16:40:13 +0200

Masahito Omote wrote:
> Probably this bug comes from uim. But I cannot reproduce.

In my case, I have been able to reproduce this very reliably for
many months (see also my CC'd message to you, May 9th).

> First, list up your environment variables. I cannot find out
> which method - XIM or GTK+ immodule you are using?

I use xim. It is incredibly difficult to produce any backtrace,
because X freezes completely. I sent some results a while ago to
the Firefox maintainer (Justin Pryzby). As this is very technical,
I suggest you discuss this issue with him. I can only tell you
what happens, not why it happens.

Thanks for looking into this. If this is not solved, I cannot
convert my wife to using Linux (the risk of X freezing is too great).

Regards, Jan

Message #26 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Masahito Omote" <omote@debian.org>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>, 377808@bugs.debian.org

Subject: Re: Bug#377808: uim can cause crash of X

Date: Wed, 12 Jul 2006 00:22:54 +0900

Hi.

2006/7/11, Jan Willem Stumpel <jstumpel@planet.nl>:
> Masahito Omote wrote:
> > Probably this bug comes from uim. But I cannot reproduce.

> In my case, I have been able to reproduce this very reliably for
> many months (see also my CC'd message to you, May 9th).

Umm..., I tested it again and again but it does not reproduce. Please
check 'uim-xim --trace > /path/to/output1 &' and 'uim-xim --trace-xim
> /path/to/output2' and give me their outputs.

And let me know what Window Manger and Session Manager you are using?

> > First, list up your environment variables. I cannot find out
> > which method - XIM or GTK+ immodule you are using?
>
> I use xim. It is incredibly difficult to produce any backtrace,
> because X freezes completely. I sent some results a while ago to
> the Firefox maintainer (Justin Pryzby). As this is very technical,
> I suggest you discuss this issue with him. I can only tell you
> what happens, not why it happens.

The easiest way to solve this problem is stop using XIM in Firefox and
Mozilla until I can fix it. Both Firefox and Mozilla supports GTK+ immodule.
Are there any reasons not to use GTK+ immodule?

And you can also attach uim-xim process by using
$ strace -p [uim-xim's pid]
or
$gdb uim-xim [uim-xim's pid]
before starting firefox process.

By these two ways, you can check uim-xim's behavior from VT, I think.

Thanks,
-- 
Masahito Omote(omote@debian.org)

Message #31 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: Masahito Omote <omote@debian.org>

Cc: Jan Willem Stumpel <jstumpel@planet.nl>, 377808@bugs.debian.org

Subject: Re: Bug#377808: uim can cause crash of X

Date: Tue, 11 Jul 2006 18:26:34 +0200

[Message part 1 (text/plain, inline)]

Masahito Omote wrote:
> Hi.
> Umm..., I tested it again and again but it does not reproduce. 
> Please check 'uim-xim --trace > /path/to/output1 &' and 
> 'uim-xim --trace-xim> /path/to/output2' and give me their outputs.

OK. At the moment I am in X (icewm) and have uim running (test: 世
界に今日は, or something like that).

The results of

   uim-xim --trace > uimxim.txt &

and

   uim-xim --trace-xim >uimxim2.txt &

are enclosed.

> And let me know what Window Manger and Session Manager you are
> using?

This bug can be reproduced with icewm, xfce4, and KDE (selected
outside X by update-alternatives --config x-session-manager). At
the moment I am using icewm (and its session manager). icewm has a
"CPU busy" indicator in the system tray, which makes it easy to
see evidence of the bug. The indicator fills up completely after I
hit CapsLock + A simultaneously. In the other window managers, you
only notice that X has mysteriously stopped responding to mouse
and keyboard commands (with the exception, fortunately, of
switching to a console VT).

> First, list up your environment variables. I cannot find
> out which method - XIM or GTK+ immodule you are using?

This is the output of the env command:

SHELL=/bin/bash
TERM=xterm
HUSHLOGIN=FALSE
WINDOWID=25165858
USER=root
XTERM_SHELL=/bin/bash
LS_COLORS=no=00:[..]
XPSERVERLIST=:64
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
XKBPATH=/usr/share/X11/xkb
QT_IM_MODULE=xim
PWD=/home/jws
XMODIFIERS=@im=uim
JAVA_HOME=/usr/lib/java
LANG=en_GB.UTF-8
PS1=\h:\w\$
XTERM_VERSION=XTerm(210)
SHLVL=4
HOME=/root
LOGNAME=root
DISPLAY=:0.0
GTK_IM_MODULE=xim
XAUTHORITY=/home/jws/.Xauthority
_=/usr/bin/env

> The easiest way to solve this problem is stop using XIM in 
> Firefox and Mozilla

How? By changing the GTK_IM_MODULE environment variable, or by
something else?

> until I can fix it. Both Firefox and Mozilla supports GTK+
> immodule. Are there any reasons not to use GTK+ immodule?

As I said in http://www.jw-stumpel.nl/stestu.html, the gtk+
immodule system is almost useless. Hardly any programs work with
it (not even Mozilla and Firefox). If you want international input
in all programs, you have to use xim. This even works in ancient
programs like xfig. Ming Hua recommends the same for scim.

> And you can also attach uim-xim process by using $ strace -p 
> [uim-xim's pid] or $gdb uim-xim [uim-xim's pid] before starting
> firefox process.

So far, I did not have success with this, because when I make
Mozilla/Firefox crash (by putting my finger down half-way between
CapsLock and A) X becomes completely unusable.

Please ask if you want more information for curing this bug.

Regards, Jan

[uimxim.txt (text/plain, inline)]

UIM-XIM bridge. Now supporting multiple locales.
Using full-synchronous XIM event flow
Supported conversion engines:
  tutcode (ja)
  tcode (ja)
  hangul2 (ko)
  hangul3 (ko)
  romaja (ko)
  viqr (vi)
  ipa-x-sampa ()
  latin ()
  byeoru (ko)
  anthy (ja)
  direct (*)
Another instance exists (uim).
aborting...

[uimxim2.txt (text/plain, inline)]

UIM-XIM bridge. Now supporting multiple locales.
Using full-synchronous XIM event flow
Supported conversion engines:
  tutcode (ja)
  tcode (ja)
  hangul2 (ko)
  hangul3 (ko)
  romaja (ko)
  viqr (vi)
  ipa-x-sampa ()
  latin ()
  byeoru (ko)
  anthy (ja)
  direct (*)
Another instance exists (uim).
aborting...

Message #36 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Masahito Omote" <omote@debian.org>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>

Cc: 377808@bugs.debian.org

Subject: Re: Bug#377808: uim can cause crash of X

Date: Wed, 12 Jul 2006 03:46:44 +0900

Hi, sorry for doubleness.

2006/7/12, Jan Willem Stumpel <jstumpel@planet.nl>:
> Masahito Omote wrote:
>
> The results of
>
>    uim-xim --trace > uimxim.txt &
>
> and
>
>    uim-xim --trace-xim >uimxim2.txt &
>
> are enclosed.

Thank you. But checking the outputs, uim-xim --trace/--trace-xim does
not work on your machine.

It is no use running secondery uim-xim process, it just exits.
If another uim-xim process is running, kill it first.

Checking the source code, uim-xim --trace --trace-xim is available.
Please try again with "uim-xim --trace --trace-xim".

> > The easiest way to solve this problem is stop using XIM in
> > Firefox and Mozilla
>
> How? By changing the GTK_IM_MODULE environment variable, or by
> something else?

GTK_IM_MODULE=uim :D

> > until I can fix it. Both Firefox and Mozilla supports GTK+
> > immodule. Are there any reasons not to use GTK+ immodule?
>
> As I said in http://www.jw-stumpel.nl/stestu.html, the gtk+
> immodule system is almost useless. Hardly any programs work with
> it (not even Mozilla and Firefox). If you want international input
> in all programs, you have to use xim. This even works in ancient
> programs like xfig. Ming Hua recommends the same for scim.

Yes, it's true we have to use XIM if we support *all* programs running in X
or run in system call emulating system such as linuxlator in such as
FreeBSD and NetBSD because it's too difficult and complicated to use
GTK+/QT immodule.

But uim project does not make much of XIM implementation.
In uim project, we recommends using toolkit's input method framework directly,
such as GTK/QT immodule. uim-xim implementation was implemented for
backword compatibility like classic applications.

uim was developed as antithesis of IIIMF and XIM.
You can learn the background of uim by checking anthy-dev(written in
Japanse) ML (2002-2003) in sourceforge.jp .

> > And you can also attach uim-xim process by using $ strace -p
> > [uim-xim's pid] or $gdb uim-xim [uim-xim's pid] before starting
> > firefox process.
>
> So far, I did not have success with this, because when I make
> Mozilla/Firefox crash (by putting my finger down half-way between
> CapsLock and A) X becomes completely unusable.

Before stating Firefox/Mozilla, go to VT and run strace -p/gdb.

Summary
1. Kill all uim-xim process and uim-xim related X applications first.
 And run new terminal.
2. uim-xim --trace --trace-xim> /path/to/output & in 1's new X terminal.
3. Go to VT and strace -p [uim-xim's pid] or gdb .
4. Run /usr/bin/firefox or /usr/bin/mozilla-browser
5. If crashed, go to VT, kill firefox/mozilla-browser process. If you
cannot go to
  VT, use CTRL+ALT+BS.
6. Do 1-5 with using gdb /usr/bin/uim-xim [uim-xim's pid] insted of strace.
7. If you have a time to check, do Justin's debug solution written in
Bug#366390.

Thanks
--
Masahito Omote(omote@debian.org)

Message #41 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: 377808@bugs.debian.org

Date: Fri, 14 Jul 2006 15:26:19 +0900

Hi,

I'm one of the developer of uim.  As far as I can tell, you can avoid
this complete freeze of
X by using --async option of uim-xim.

I think this bug is caused from invalid use of filter key event in
mozilla in the address bar widget.  Even if you use uim-xim --async
(or maybe SCIM's x11 module), CPU usage may
increase to 100% while inputting some characters with completed
addresses below address widget popup, but in this case mozilla won't
freeze at all.

By the way, you seem to like using XIM instead of gtk+ immodule
because of the compose sequences in X11.  I think you can try uim's
gtk+ immodule with latin IM (selecting "Latin characters" from
toolbar) enabled.  It support most of the sequence in X's compose
sequence using Compose key (bug dead key is not supported yet).  You
can modify this table if you like.  Please check the table in
/usr/share/uim/latin.scm.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #46 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: 377808@bugs.debian.org

Cc: ek.kato@gmail.com

Subject: Re : uim can cause crash of X

Date: Sun, 16 Jul 2006 13:00:20 +0200

Etsushi Kato wrote:

> I'm one of the developer of uim.  As far as I can tell, you can
> avoid this complete freeze of X by using --async option of 
> uim-xim.

Thank you!!! This indeed works. In Debian Sid, I set
XIM_ARGS=--async, and indeed it works now exactly as you said: CPU
usage goes to 100% when I 'mis-hit' keys, but this is temporary
and X does not freeze.

> I think this bug is caused from invalid use of filter key event
> in mozilla in the address bar widget.  

So you agree it is a bug? Can you reproduce it? If it is a bug in
Mozilla/Firefox, somebody should report it, but I'm afraid I do
not have the technical knowledge about 'filter key events'to
describe it exactly.

> Even if you use uim-xim
> --async (or maybe SCIM's x11 module), CPU usage may increase to
> 100% while inputting some characters with completed addresses
> below address widget popup, but in this case mozilla won't
> freeze at all.



> By the way, you seem to like using XIM instead of gtk+ immodule
> because of the compose sequences in X11.  I think you can try
> uim's gtk+ immodule with latin IM (selecting "Latin
> characters" from toolbar) enabled.  It support most of the
> sequence in X's compose sequence using Compose key (bug dead
> key is not supported yet).

> You can modify this table if you like.  Please check the table
> in /usr/share/uim/latin.scm.

> Cheers, -- Etsushi Kato ek.kato@gmail.com

Message #51 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: 377808@bugs.debian.org

Cc: ek.kato@gmail.com

Subject: Re : uim can cause crash of X

Date: Sun, 16 Jul 2006 13:21:54 +0200

(Sorry, hit the "send" button too soon)

Etsushi Kato wrote:

> I'm one of the developer of uim.  As far as I can tell, you can
> avoid this complete freeze of X by using --async option of 
> uim-xim.

Thank you!!! This indeed works. In Debian Sid, I set
XIM_ARGS=--async in /etc/X11/xinit/xinput.d/uim-systray, and
indeed it works now exactly as you said: CPU usage goes to 100%
when I 'mis-hit' keys, but this is temporary and X does not
freeze. If no side effects are expected, I would vote for "async"
to be the default. I just wonder why Omote-san could not reproduce
this.

> I think this bug is caused from invalid use of filter key event
> in mozilla in the address bar widget.  

So you agree it is a bug? Can you reproduce it? If it is a bug in
Mozilla/Firefox, somebody should report it, but I'm afraid I do
not have the technical knowledge about 'filter key events' to
describe it exactly.

> [..]

> By the way, you seem to like using XIM instead of gtk+ immodule
> because of the compose sequences in X11. 

Two reasons:

1 - the compose sequences. With uim default method = "direct", it
    is as if uim does not exist. There is just the arrow symbol in
    the systray. All the xkb/compose stuff works (not so with
    SCIM, that ís why I like uim better!). But if I want to use
    uim, it is there, and I can activate it by right-clicking on
    the arrow.
2 - xim always works. When I activate uim, I can use it
    everywhere: xterm programs, openoffice, qt programs, gtk
    programs, mozilla, even in xfig. Very simple, very neat.

Thanks again,

Jan

Message #56 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>

Cc: 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Mon, 17 Jul 2006 18:28:09 +0900

On 7/16/06, Jan Willem Stumpel <jstumpel@planet.nl> wrote:
> > I'm one of the developer of uim.  As far as I can tell, you can
> > avoid this complete freeze of X by using --async option of
> > uim-xim.
>
> Thank you!!! This indeed works. In Debian Sid, I set
> XIM_ARGS=--async in /etc/X11/xinit/xinput.d/uim-systray, and
> indeed it works now exactly as you said: CPU usage goes to 100%
> when I 'mis-hit' keys, but this is temporary and X does not
> freeze. If no side effects are expected, I would vote for "async"
> to be the default. I just wonder why Omote-san could not reproduce
> this.

Hmm...  It it known that --async option has a side effect (and also
SCIM's x11 has) in inputting characters into Tck/Tk widget.  We cannot
input any character in Tcl/Tk version below 8.4.13.  And I think
our default behavior (not using --async) is suitable for old
applications like xfig and tgif.

> > I think this bug is caused from invalid use of filter key event
> > in mozilla in the address bar widget.
>
> So you agree it is a bug? Can you reproduce it? If it is a bug in
> Mozilla/Firefox, somebody should report it, but I'm afraid I do
> not have the technical knowledge about 'filter key events' to
> describe it exactly.

Yes, I can reproduce it.  But the bug is very difficult to describe
and solve.  IMHO, It can be said that the bug is in mozilla's complex
use of filter key event (how to handle key event) in term of XIM, but it
is indeed a problem in libX11's XIM protocol.  With gtk+ immodule other
than XIM (i.e. other than im-xim.so), this cannot be said a bug in
mozilla and it works perfectly.  X11's XIM protocol is not well defined
and not suitable for such a complex use of key filter event like mozilla.
This is why we recommend to abandon XIM.

> > By the way, you seem to like using XIM instead of gtk+ immodule
> > because of the compose sequences in X11.
>
> Two reasons:
>
> 1 - the compose sequences. With uim default method = "direct", it
>     is as if uim does not exist. There is just the arrow symbol in
>     the systray. All the xkb/compose stuff works (not so with
>     SCIM, that ís why I like uim better!). But if I want to use
>     uim, it is there, and I can activate it by right-clicking on
>     the arrow.
> 2 - xim always works. When I activate uim, I can use it
>     everywhere: xterm programs, openoffice, qt programs, gtk
>     programs, mozilla, even in xfig. Very simple, very neat.

I see.

For 1,

I've implemented X11's equivalent compose mechanism in uim-xim, so it
should work as if it doesn't exit :).

In gtk+ (Qt), maybe you can ask developers of gtk+ (Qt) directly to
support all the compose sequences of X11's.  Or maybe I can implement
uim's immodule to support them.  Also I as noted in previous mail,
please test uim's Latin IM with uim immodule (if you can find a bug
or request to it, please file a bug in uim's bugzilla at freedesktop.org).



For 2,

That's true.  But as I described above, XIM protocol is not very easy
to implement in a application properly (because XIM is not well
designed IMHO), and gtk+ or qt's immodule is more robust in complex
use of inputting mechanism.  So if a application support immodule and
uim or SCIM immodule is available, we recommend use uim (SCIM)
immodule.

So, just set GTK_IM_MODULE=uim and QT_IM_MODULE=uim environmental
variable.  And for the rest of traditional applications, just run
uim-xim at startup of X and set XMODIFIERS=@im=uim.  With this
setting, you can use uim everywhere.  It not so complex.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #61 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: Etsushi Kato <ek.kato@gmail.com>

Cc: 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Mon, 17 Jul 2006 16:32:33 +0200

Etsushi Kato wrote:

> Hmm...  It it known that --async option has a side effect (and
> also SCIM's x11 has) in inputting characters into Tck/Tk 
> widget.

This is true, unfortunately; I installed tkpaint and no input was
possible. In fact X froze. I had to go to the console to kill
tkpaint. Tcl/tk version is 8.4.12. Without --async, tkpaint works.

> And I think our default behavior (not using --async) is 
> suitable for old applications like xfig and tgif.

xfig works 'more or less all right' with xfig -international both
with and without --async. It never works really well, of course;
this old program has no idea of UTF-8, ttf fonts, etc.

> [..] Yes, I can reproduce it.  But the bug is very difficult to
> describe and solve. [..] This is why we recommend to abandon 
> XIM.

>>> By the way, you seem to like using XIM instead of gtk+ 
>>> immodule because of the compose sequences in X11.

>> Two reasons:

>> 1 - the compose sequences. [..] 
>> 2 - xim always works. [..]

> I see. For 1, I've implemented X11's equivalent compose 
> mechanism in uim-xim, so it should work as if it doesn't exist
> :).

Yes; uim-xim apparently uses the actual X compose mechanism (if
that is the right term), including the user's ~/.XCompose file. It
seems SCIM has it own internal version of the Compose file. So
with SCIM, the user's customisations do not work (for instance
things I like to have, such as Compose .- -> …, Compose /\ -> ∧,
Compose \/ -> ∨). But they work with uim.

Mozilla and Thunderbird (and other GTK programs) seem to have
their own 'internal' compose table, which is much smaller than the
X Compose table. Some compose sequences work (like Compose ss ->
ß), but more unusual ones do not (like Compose Uu -> ŭ, which is
an easy test case). This is if you use GTK_IM_MODULE=uim. With
GTK_IM_MODULE=xim, Mozilla handles all Compose sequences.
Unfortunately Mozilla & Co (unlike 'normal' GTK programs like
Bluefish) do not offer an easy way to change between the xim and
uim input methods.

> Also I as noted in previous mail, please test uim's Latin IM 
> with uim immodule [..]

The 'Latin' IM can indeed do some things which Mozilla cannot do
by itself, like ŭ. But it still does not offer all the
possibilities of the full X Compose file; only Latin combinations,
e.g. no accented Greek letters (such as these nice things with
three accents, like ᾇ). IMHO it would be a waste to duplicate them
in uim, because they are already a standard feature in X. If you
ask me, the 'Latin' IM can be removed completely.

> For 2, That's true. [..] So, just set GTK_IM_MODULE=uim and 
> QT_IM_MODULE=uim environmental variable.  And for the rest of 
> traditional applications, just run uim-xim at startup of X and 
> set XMODIFIERS=@im=uim.  With this setting, you can use uim 
> everywhere. It not so complex.

Yes, this is completely true, thanks. Ι had to install uim-qt (not
default in Debian), but then I could indeed use uim 'everywhere',
also with GTK_IM_MODULE=uim and QT_IM_MODULE=uim. But then I had
the problem with Compose in Mozilla.

So now we have three choices:

xim         -> may crash Mozilla and X when used in URL field
               (because of the automatic 'history' drop-down
               box?).
xim --async -> crashes Tcl/tk apps with input fields (until
               version 8.4.14?).
uim         -> no complete compose mechanism in Mozilla (not even
               with uim/Latin). I think this is pretty serious
               because many people use Mozilla/Thunderbird as
               mail clients. Mail is often very international..

The easiest, apparently, is to wait for Tcl 8.4.14. But for a
fundamental solution, I would say that xim handling in Mozilla
(or libX11?) should be fixed. Something that works across the
whole system is always to be preferred. That way, users do not get
surprises. This is just a non-programmer's opinion of course..

Regards, Jan
http://www.jw-stumpel.nl/stestu.html

Message #66 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>

Cc: 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Tue, 18 Jul 2006 05:02:47 +0900

On 7/17/06, Jan Willem Stumpel <jstumpel@planet.nl> wrote:
> >> Two reasons:
>
> >> 1 - the compose sequences. [..]
> >> 2 - xim always works. [..]
>
> > I see. For 1, I've implemented X11's equivalent compose
> > mechanism in uim-xim, so it should work as if it doesn't exist
> > :).
>
> Yes; uim-xim apparently uses the actual X compose mechanism (if
> that is the right term), including the user's ~/.XCompose file. It
> seems SCIM has it own internal version of the Compose file. So
> with SCIM, the user's customisations do not work (for instance
> things I like to have, such as Compose .- -> …, Compose /\ -> ∧,
> Compose \/ -> ∨). But they work with uim.

Right.

> > Also I as noted in previous mail, please test uim's Latin IM
> > with uim immodule [..]
>
> The 'Latin' IM can indeed do some things which Mozilla cannot do
> by itself, like ŭ. But it still does not offer all the
> possibilities of the full X Compose file; only Latin combinations,
> e.g. no accented Greek letters (such as these nice things with
> three accents, like ᾇ). IMHO it would be a waste to duplicate them
> in uim, because they are already a standard feature in X. If you
> ask me, the 'Latin' IM can be removed completely.

Yep,  Latin IM is still experimental one.  But it is easily extensible
as it is just a compose table in a text file, as you can see in
$prefix/share/uim/latin.scm.  Also user can modify it in ~/.uim.

Still, I agree with you that using X Compose file depending on working
locale and ~/.XCompose is more consistent in X11 environment.

> > For 2, That's true. [..] So, just set GTK_IM_MODULE=uim and
> > QT_IM_MODULE=uim environmental variable.  And for the rest of
> > traditional applications, just run uim-xim at startup of X and
> > set XMODIFIERS=@im=uim.  With this setting, you can use uim
> > everywhere. It not so complex.
>
> Yes, this is completely true, thanks. Ι had to install uim-qt (not
> default in Debian), but then I could indeed use uim 'everywhere',
> also with GTK_IM_MODULE=uim and QT_IM_MODULE=uim. But then I had
> the problem with Compose in Mozilla.

See below.

> So now we have three choices:
>
> xim         -> may crash Mozilla and X when used in URL field
>                (because of the automatic 'history' drop-down
>                box?).
> xim --async -> crashes Tcl/tk apps with input fields (until
>                version 8.4.14?).
> uim         -> no complete compose mechanism in Mozilla (not even
>                with uim/Latin). I think this is pretty serious
>                because many people use Mozilla/Thunderbird as
>                mail clients. Mail is often very international..

4) uim     -> implement X's equivalent compose mechanism in uim's
                 gtk+ immodule and Qt immodule.  It is fairly easy since
                 we already have it in uim-xim.  And I just tested to port this
                 in uim's gtk+ immodule, it works pretty well.


We have a release plan of uim-1.2.0 in this month, and this feature can
be put into it.  If so you will be able to use uim all the environment and
all the X's compose input with it.  What do you think?


> The easiest, apparently, is to wait for Tcl 8.4.14. But for a
> fundamental solution, I would say that xim handling in Mozilla
> (or libX11?) should be fixed. Something that works across the
> whole system is always to be preferred. That way, users do not get
> surprises. This is just a non-programmer's opinion of course..

IMHO, XIM protocol is badly designed, and no one seems to fix it.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #71 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>

Cc: 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Tue, 18 Jul 2006 13:05:18 +0900

On 7/18/06, Etsushi Kato <ek.kato@gmail.com> wrote:
> 4) uim     -> implement X's equivalent compose mechanism in uim's
>                   gtk+ immodule and Qt immodule.  It is fairly easy since
>                   we already have it in uim-xim.  And I just tested to port this
>                   in uim's gtk+ immodule, it works pretty well.

I committed the changes for gtk+ and Qt immodule on freedesktop's svn
repository while ago.  Now you can use all compose sequences and
~/.XCompose with gtk+ (Mozilla, Firefox, Thunderbird, Gedit and so on)
and Qt (Kate, ...) immodules of uim as well as XIM.

You can download source code and try them from
svn://anonsvn.freedesktop.org/svn/uim/trunk/ using svn.  Or wait
1.2.0-alpha release.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #76 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: Etsushi Kato <ek.kato@gmail.com>

Cc: Jan Willem Stumpel <jstumpel@planet.nl>, 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Tue, 18 Jul 2006 09:40:02 +0200

Etsushi Kato wrote:
> On 7/18/06, Etsushi Kato <ek.kato@gmail.com> wrote:
 > I committed the changes for gtk+ and Qt immodule on
> freedesktop's svn repository while ago.  Now you can use all
> compose sequences and ~/.XCompose with gtk+ (Mozilla, Firefox,
> Thunderbird, Gedit and so on) and Qt (Kate, ...) immodules of
> uim as well as XIM.

Unless I am mistaken, in the present version (1.1.0) I can already
input all Compose sequences in Qt programs (with the uim input
method). Only in GTK programs and Mozilla do I have to use the xim
input method with 1.1.0.

> You can download source code and try them from 
> svn://anonsvn.freedesktop.org/svn/uim/trunk/ using svn.  Or
> wait 1.2.0-alpha release.

I'll try if I can compile it, and if not I'll wait. Thanks very
much for this quick work.

For Debian this would mean

-- making the uim input method the default
-- including uim-qt in the "uim" metapackage.

I think this change would make the Latin IM superfluous, doesn't
it? Because all Latin (and also all other) accented letters will
be available with all input methods when conversion is switched
off (shift-space).

Regards, Jan

Message #81 received at 377808@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: "Jan Willem Stumpel" <jstumpel@planet.nl>

Cc: 377808@bugs.debian.org

Subject: Re: Re : uim can cause crash of X

Date: Wed, 19 Jul 2006 16:24:45 +0900

On 7/18/06, Jan Willem Stumpel <jstumpel@planet.nl> wrote:
> Etsushi Kato wrote:
> > On 7/18/06, Etsushi Kato <ek.kato@gmail.com> wrote:
>  > I committed the changes for gtk+ and Qt immodule on
> > freedesktop's svn repository while ago.  Now you can use all
> > compose sequences and ~/.XCompose with gtk+ (Mozilla, Firefox,
> > Thunderbird, Gedit and so on) and Qt (Kate, ...) immodules of
> > uim as well as XIM.
>
> Unless I am mistaken, in the present version (1.1.0) I can already
> input all Compose sequences in Qt programs (with the uim input
> method). Only in GTK programs and Mozilla do I have to use the xim
> input method with 1.1.0.

Qt immodule patch has its own compose table internally based on X11's
Compose file, but it doesn't support ~/.XCompose and changing Compose
file depending on working locale.  It is just a static table compiled
with in the
library.


> I think this change would make the Latin IM superfluous, doesn't
> it? Because all Latin (and also all other) accented letters will
> be available with all input methods when conversion is switched
> off (shift-space).

Completely right.  But it has one advantage that it can show
preedit while inputting accented letters.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #86 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Jan Willem Stumpel <jstumpel@planet.nl>

To: 377808@bugs.debian.org

Subject: Crash no longer occurs in uim 1.2

Date: Sat, 20 Jan 2007 11:46:07 +0100

This bug can be closed as it does not occur anymore in uim 1.2,
provided QT_IM_MODULE and GTK_IM_MODULE are set to uim.

The present version of im-switch still sets them both to xim,
however.

Regards, Jan

Message #91 received at 377808@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <charles-debian-nospam@plessy.org>

To: Debian Bug Tracking System <377808@bugs.debian.org>

Subject: Bug still present in Etch, depends on .xinput.d

Date: Mon, 14 May 2007 21:43:00 +0900

Package: uim
Version: 1:1.2.1-9
Followup-For: Bug #377808

Greetings maintainers, developpers, and bug victims :)

I suffered from this bug on a freshly installed Etch system, with
symptoms in iceweasel and nautilus:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412053
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422758

I was quite surprised, because on my home computer running Etch, I have
no problems with these programs. I finally managed to figure out that
the contents of $HOME/.xinput.d are different in both machines, and that
the safe one is not available on the crashing mashine.

Crash:
-------------------------------------------------------
# UIM with GTK systray indicator
XIM=uim
XIM_PROGRAM=/usr/bin/uim-xim
XIM_ARGS=
GTK_IM_MODULE=xim
QT_IM_MODULE=xim
# It seems to me that the system needs to be initialized.
# Folowing trick will wait 10 seconds without slowing down X start up.
XIM_PROGRAM_XTRA="(sleep 10; uim-toolbar-gtk-systray)"
DEPENDS="uim-xim,uim-gtk2.0|uim-qt,uim-anthy|uim-canna|uim-prime|uim-skk|uim-m17nlib"
--------------------------------------------------------


No crash:
--------------------------------------------------------
XIM=uim
XIM_PROGRAM=/usr/bin/uim-xim
XIM_ARGS=
GTK_IM_MODULE=uim
ENGINE=anthy

if [ -r "$HOME/.uim" ]; then
  TMPFILE=$(mktemp) || exit 1
  if [ "$(grep "; IM-SWITCH VALUE" $HOME/.uim)" ]; then
    sed "s/(define default-im-name '[^)]*) ; IM-SWITCH VALUE/(define default-im-name '$ENGINE) ; IM-SWITCH VALUE/" <
$HOME/.uim > $TMPFILE
  else
    cat $HOME/.uim > $TMPFILE
    if [ "$(grep -E "^\(define[[:space:]]+default-im-name[[:space:]]" $HOME/.uim)" ]; then
      echo "; (define default-im-name '$ENGINE) ; IM-SWITCH VALUE" >> $TMPFILE
    else
      echo "(define default-im-name '$ENGINE) ; IM-SWITCH VALUE" >> $TMPFILE
    fi
  fi
  mv $TMPFILE $HOME/.uim
else
  echo "(define default-im-name '$ENGINE) ; IM-SWITCH VALUE" > $HOME/.uim
fi
--------------------------------------------------------

What shall I do with the iceweasel and nautilus bugs ?

Have a nice day,

-- Charles Plessy, Wako, Saitama, Japan

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-powerpc64
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages uim-xim depends on:
ii  libatk1.0-0               1.12.4-3       The ATK accessibility toolkit
ii  libc6                     2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libcairo2                 1.2.4-4        The Cairo 2D vector graphics libra
ii  libfontconfig1            2.4.2-1.2      generic font configuration library
ii  libgcc1                   1:4.1.1-21     GCC support library
ii  libglib2.0-0              2.12.4-2       The GLib library of C routines
ii  libgtk2.0-0               2.8.20-7       The GTK+ graphical user interface 
ii  libpango1.0-0             1.14.8-5       Layout and rendering of internatio
ii  libpng12-0                1.2.15~beta5-1 PNG library - runtime
ii  libstdc++6                4.1.1-21       The GNU Standard C++ Library v3
ii  libuim3                   1:1.2.1-9      Simple and flexible input method c
ii  libx11-6                  2:1.0.3-7      X11 client-side library
ii  libxcursor1               1.1.7-4        X cursor management library
ii  libxext6                  1:1.0.1-2      X11 miscellaneous extension librar
ii  libxfixes3                1:4.0.1-5      X11 miscellaneous 'fixes' extensio
ii  libxft2                   2.1.8.2-8      FreeType-based font drawing librar
ii  libxi6                    1:1.0.1-4      X11 Input extension library
ii  libxinerama1              1:1.0.1-4.1    X11 Xinerama extension library
ii  libxrandr2                2:1.1.0.2-5    X11 RandR extension library
ii  libxrender1               1:0.9.1-3      X Rendering Extension client libra
ii  uim-common                1:1.2.1-9      Common files for uim
ii  uim-utils                 1:1.2.1-9      Utilities for uim
ii  zlib1g                    1:1.2.3-13     compression library - runtime

uim-xim recommends no packages.

-- no debconf information

Message #96 received at 377808@bugs.debian.org (full text, mbox, reply):

From: d+deb@vdr.jp

To: control@bugs.debian.org

Cc: 400871@bugs.debian.org, 377808@bugs.debian.org, 412053@bugs.debian.org, 422758@bugs.debian.org

Subject: uim crashing depends on .xinput.d

Date: Thu, 3 Jun 2010 00:41:08 +0900

[Message part 1 (text/plain, inline)]

package 422758 uim
forcemerge 377808 400871 412053 422758
retitle 377808 uim crashing depends on .xinput.d
fixed 377808 1:1.3.1-1
thanks
-- 
Regards,
	dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

[signature.asc (application/pgp-signature, inline)]

Message #105 received at 377808@bugs.debian.org (full text, mbox, reply):

From: d+deb@vdr.jp

To: control@bugs.debian.org

Cc: 377808@bugs.debian.org

Subject: Re: uim crashing depends on .xinput.d

Date: Thu, 3 Jun 2010 01:07:44 +0900

[Message part 1 (text/plain, inline)]

reassign 422758 uim
forcemerge 377808 400871 412053 422758
tags 377808 fixed-in-experimental
thanks

sorry for my mistake.
-- 
Regards,
	dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

[signature.asc (application/pgp-signature, inline)]

Message #112 received at 377808-done@bugs.debian.org (full text, mbox, reply):

From: d+deb@vdr.jp

To: 377808-done@bugs.debian.org

Subject: Re: uim crashing depends on .xinput.d

Date: Sun, 6 Feb 2011 13:57:29 +0900

[Message part 1 (text/plain, inline)]

this bug is already fixed and uim 1.2.1 is in archive,
so I close it.
-- 
Regards,
	dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.