Red Hat Bugzilla – Bug 201284
XIM hangs when switching Input Context
Last modified: 2014-06-18 05:08:25 EDT
Description of problem:
Sometimes a KDE app will not accept inputs anymore (even input method is not
activated). The only thing I can do to have input again is change to "Simple
Composing Input Method" which is a test input method module in Qt, or restart
Steps to Reproduce:
1. Use a KDE app long enough
No inputs were outputted
Output english letters
Yep, I think I saw this on KDE desktop while testing this morning.
Need to test with another IM to see if it is a kde/qt problem or
issue with scim. XIM seems to work fine with other apps.
Reproducible in FC6 devel using the following test case by Choe Hwanjin:
1. $ export XMODIFIERS=@im=SCIM
2. $ export GTK_IM_MODULE=xim
3. $ gedit/kedit
4. press ctrl-N
5. try to type something
for more details. It seems like that this is a xorg-x11 regression according to
Reproduced on fc5 and fc6. RHEL4 and fc4 seem ok.
gedit loops with kinput2 and uim xim on rawhide.
Adding upstream bug from the thread referred to in comment #3 above for tracking:
(Problem also occurs with gcin fwiw.)
I'm not easily able to reproduce the problem on kde apps.
A workaround for gtk xim at least seems to be to set "/FrontEnd/X11/Dynamic = true"
in .scim/config (but that breaks deadkey support under XIM direct input).
This can also easily be reproduced with kinput2 and gedit.
1. setup kinpu2 and restart desktop
2. run gedit
3. activate kinput2 with Shift-Space and press Ctrl-n
at this point gedit goes into a hard loop.
Also reproduced with libX11-0.99.3 fwiw.
Here is a backtrace of where gedit loops with kinput2:
#0 XIfEvent (dpy=0x6ca790, event=0x7fff84fd6000,
predicate=0x2aaaaab427a0 <_CheckCMEvent>, arg=0x10b4000 " \220ÃÂªÃ¯Â¿Â½*")
#1 0x00002aaaaab42cea in _XimXRead (im=0x10b4000, recv_buf=0x7fff84fd61f0 "",
buf_len=2048, ret_len=0x7fff84fd6144) at imTrX.c:446
#2 0x00002aaaaab45f86 in _XimReadData (im=0x10b4000, len=0x7fff84fd61a6,
buf=0x7fff84fd61f0 "", buf_size=2048) at imTransR.c:154
#3 0x00002aaaaab46323 in _XimRead (im=0x10b4000, len=0x7fff84fd71fe,
buf=0x7fff84fd61f0 "", buf_size=2048,
predicate=0x2aaaaab48c20 <_XimSyncCheck>, arg=0x10b8800 "\200\217ÃÂªÃ¯Â¿Â½*")
#4 0x00002aaaaab49d0e in _XimForwardEvent (ic=0x10b8800, ev=0x7fff84fd7290,
sync=1) at imDefLkup.c:296
#5 0x00002aaaaab39c8b in _XimFilterKeypress (d=<value optimized out>,
w=<value optimized out>, ev=0x7fff84fd7290,
client_data=<value optimized out>) at imDefFlt.c:187
#6 0x00002aaaaaaf9104 in XFilterEvent (ev=0x7fff84fd7290,
window=<value optimized out>) at FilterEv.c:99
#7 0x00002aaab4e7fecd in gtk_im_context_xim_register_type ()
(In reply to comment #8)
> I'm not easily able to reproduce the problem on kde apps.
I can reproduce this fine now with "QT_IM_MODULE=xim kedit".
It is not reproduceable in my rawhide. (20061018)
(according to comment #2)
According to the procedures mentioned in comment #2; though it is not
reproduceable, the scim also could not able to be activated as well.
FYI, clone of this bug for RHEL5: bug #209285 could be reproduced instead.
(In reply to comment #17)
> the scim also could not able to be activated as well.
The XIM client needs to be running in order to reproduce this.
As far as I can see, this is what is going on:
- application gets normal keyboard event from X server
- application forwards event to IM server
- application unfocuses IM context
- application receives processed event from IM server, that requires a sync
- xim never sees this event since it has unregistered the filter
when it unfocused the ic. So no sync reply is sent.
- application focuses another IC, and sends events, which the IM server then
ignores since it hasn't gotten the SYNC_REPLY.
However, there is another weird bug: Just pressing and releasing Ctrl on a gedit
window causes it to loop infinitely processing keypresses. I'm not sure what's
going on with that or whether it's related.
Some more information about the infinite loop: It looks like
- gtk+ receives a keypress (Ctrl)
- gedit sees the event, and propagates it to the TextView,
which calls XFilterEvent()
- XFilterEvent() forwards the event to scim and returns FALSE.
- A fabricated event then arrives from scim
- gedit sends this to XFilterEvent()
- xim ignores this event, since it knows that it was fabricated
- gedit then sends the event once again to XFilterEvent()
- xim doesn't think this one is fabricated, so it forwards it to scim
- a fabricated event arrives, and gedit once again filters it twice.
So the root of the infinite loop bug is that gedit calls XFilterEvent() twice
for a single event. Or maybe the root cause is that XIM thinks generating events
behind the application's back is not stupid.
Created attachment 139010 [details]
So the infinite loop is GEdit understandably misunderstanding XIM. The getting
stuck bug is reproduced by this gtk+ program which just switches focus in
response to a keypress, before gtk+ gets a chance to deal with the fabricated
I guess the fix is this:
When a fabricated event arrives for an unfocused input context, instead of
ignoring it, process it, and pass it on to the application, which should be
prepared for events appearing on unfocused ic's anyway, due to the asynchronous
nature of X.
Thanks, Soeren. Yup, your reproducer works just fine for me too.
By "works just fine for me", I assume you mean that it reproduces the bug.
I don't really see how this could be a regression though. Could you try if the
reproducer also reproduces on RHEL4?
(In reply to comment #24)
> By "works just fine for me", I assume you mean that it reproduces the bug.
Yes, that's right.
> I don't really see how this could be a regression though. Could you try if the
> reproducer also reproduces on RHEL4?
Yes it reproduces on rhel4 too, but gedit and kate don't exhibit the problem there.
Tested on rawhide, the problem has been fixed.
devel branch & FC6 branch are patched and built.
libX11-1.0.3-5.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.