Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 201284 - XIM hangs when switching Input Context
Summary: XIM hangs when switching Input Context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libX11
Version: 6
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
 
Reported: 2006-08-04 00:55 UTC by Leon Ho
Modified: 2014-06-18 09:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-14 00:43:03 UTC


Attachments (Terms of Use)
Reproducer (deleted)
2006-10-20 18:06 UTC, Søren Sandmann Pedersen
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 7869 None None None Never

Description Leon Ho 2006-08-04 00:55:49 UTC
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 05:56:02 UTC
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-15 02:21:29 UTC
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-15 02:54:45 UTC
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 09:42:37 UTC
Reproduced on fc5 and fc6.  RHEL4 and fc4 seem ok.

Comment 5 Jens Petersen 2006-08-17 13:29:34 UTC
gedit loops with kinput2 and uim xim on rawhide.

Comment 6 Kevin E. Martin 2006-08-18 15:12:13 UTC
Adding upstream bug from the thread referred to in comment #3 above for tracking:
  https://bugs.freedesktop.org/show_bug.cgi?id=7869


Comment 7 Jens Petersen 2006-08-19 05:38:37 UTC
(Problem also occurs with gcin fwiw.)

Comment 8 Jens Petersen 2006-08-19 10:03:40 UTC
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 04:21:13 UTC
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 09:38:51 UTC
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 04:01:41 UTC
(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 04:47:51 UTC
It is not reproduceable in my rawhide. (20061018)
(according to comment #2)

Comment 17 Caius Chance 2006-10-18 05:02:33 UTC
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 05:37:01 UTC
(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 23:38:36 UTC
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
  reply.
- 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 21:09:14 UTC
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 18:06:10 UTC
Created attachment 139010 [details]
Reproducer

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
event.

Comment 22 Søren Sandmann Pedersen 2006-10-20 20:53:36 UTC
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 08:12:49 UTC
Thanks, Soeren.  Yup, your reproducer works just fine for me too.

Comment 24 Søren Sandmann Pedersen 2006-10-23 16:00:09 UTC
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 04:32:46 UTC
(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-09 02:54:09 UTC
Tested on rawhide, the problem has been fixed.

Comment 29 Caius Chance 2006-11-09 05:05:50 UTC
devel branch & FC6 branch are patched and built.

Comment 30 Fedora Update System 2006-11-09 16:58:09 UTC
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.