Bug 201284 - XIM hangs when switching Input Context
XIM hangs when switching Input Context
Product: Fedora
Classification: Fedora
Component: libX11 (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Søren Sandmann Pedersen
: i18n
Depends On:
Blocks: FC6Target 209085
  Show dependency treegraph
Reported: 2006-08-03 20:55 EDT by Leon Ho
Modified: 2014-06-18 05:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-13 19:43:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Reproducer (1.15 KB, text/x-csrc)
2006-10-20 14:06 EDT, Søren Sandmann Pedersen
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 7869 None None None Never

  None (edit)
Description Leon Ho 2006-08-03 20:55:49 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
the application.

How reproducible:
not everytime

Steps to Reproduce:
1. Use a KDE app long enough
Actual results:
No inputs were outputted

Expected results:
Output english letters
Comment 1 Jens Petersen 2006-08-08 01:56:02 EDT
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.
Comment 2 Leon Ho 2006-08-14 22:21:29 EDT
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
Comment 3 Jens Petersen 2006-08-14 22:54:45 EDT
See http://sourceforge.net/mailarchive/forum.php?thread_id=30112584&forum_id=43684
for more details.  It seems like that this is a xorg-x11 regression according to
discussion there.
Comment 4 Jens Petersen 2006-08-15 05:42:37 EDT
Reproduced on fc5 and fc6.  RHEL4 and fc4 seem ok.
Comment 5 Jens Petersen 2006-08-17 09:29:34 EDT
gedit loops with kinput2 and uim xim on rawhide.
Comment 6 Kevin E. Martin 2006-08-18 11:12:13 EDT
Adding upstream bug from the thread referred to in comment #3 above for tracking:
Comment 7 Jens Petersen 2006-08-19 01:38:37 EDT
(Problem also occurs with gcin fwiw.)
Comment 8 Jens Petersen 2006-08-19 06:03:40 EDT
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).
Comment 9 Jens Petersen 2006-08-20 00:21:13 EDT
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.
Comment 10 Jens Petersen 2006-08-20 05:38:51 EDT
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ݪ�*")
    at IfEvent.c:58
#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ݪ�*")
    at imTransR.c:231
#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 ()
   from /usr/lib64/gtk-2.0/2.10.0/immodules/im-xim.so
Comment 15 Jens Petersen 2006-09-19 00:01:41 EDT
(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".
Comment 16 Caius Chance 2006-10-18 00:47:51 EDT
It is not reproduceable in my rawhide. (20061018)
(according to comment #2)
Comment 17 Caius Chance 2006-10-18 01:02:33 EDT
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.
Comment 18 Jens Petersen 2006-10-18 01:37:01 EDT
(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.
Comment 19 Søren Sandmann Pedersen 2006-10-18 19:38:36 EDT
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.
Comment 20 Søren Sandmann Pedersen 2006-10-19 17:09:14 EDT
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.
Comment 21 Søren Sandmann Pedersen 2006-10-20 14:06:10 EDT
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
Comment 22 Søren Sandmann Pedersen 2006-10-20 16:53:36 EDT
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.
Comment 23 Jens Petersen 2006-10-23 04:12:49 EDT
Thanks, Soeren.  Yup, your reproducer works just fine for me too.
Comment 24 Søren Sandmann Pedersen 2006-10-23 12:00:09 EDT
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?
Comment 25 Jens Petersen 2006-10-26 00:32:46 EDT
(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.
Comment 28 Caius Chance 2006-11-08 21:54:09 EST
Tested on rawhide, the problem has been fixed.
Comment 29 Caius Chance 2006-11-09 00:05:50 EST
devel branch & FC6 branch are patched and built.
Comment 30 Fedora Update System 2006-11-09 11:58:09 EST
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.

Note You need to log in before you can comment on or make changes to this bug.