Bug 530768 – app-i18n/ibus app-i18n/scim - Input Methods relying on IMdkit for XIM support are susceptible to causing hangs in X clients due to improper requests from the input method to the X server

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description klemensbaum 2014-11-26 13:59:07 UTC]

Created attachment 390336 [details, diff]
IMdkit: Track window property offsets correctly

Problem symptoms

Input Methods relying on IMdkit for XIM support are susceptible to causing
hangs in X clients due to improper requests from the input method to the X server.

The problem is especially likely to occur when holding a key down while the X client is processing its event loop slowly, due to computation or I/O intensive tasks.

The following bug reports by users are related to this issue:

    https://www.libreoffice.org/bugzilla/show_bug.cgi?id=78081
    https://bugzilla.redhat.com/show_bug.cgi?id=452849#c19
    http://tracker.xemacs.org/XEmacs/its/issue565
    https://code.google.com/p/ibus/issues/detail?id=1751
    https://code.google.com/p/ibus/issues/detail?id=1697
    https://code.google.com/p/ibus/issues/detail?id=862
    http://lists.schmorp.de/pipermail/rxvt-unicode/2010q2/001176.html

Patches submitted upstream:

    https://github.com/scim-im/scim/pull/1
    https://github.com/ibus/ibus/pull/14

Since the patches should apply cleanly onto all versions of ibus and scim in the portage tree, I propose that we add them manually and revbump the affected ebuilds.

---

Detailed description of the bug

The XIM specification requires that XIM tranports over 20 bytes in size
be transferred via window properties. The sender calls XChangeProperty
with PropModeAppend, and instructs the recipient via ClientMessage to
call XGetWindowProperty with delete set to True.

Naive implementations exhibit a race condition because the receiver
could have written more data in the meantime, and XGetWindowProperty
only deletes the property when bytes_after_return is zero. If
bytes_after_return is non-zero, it is necessary to use an offset when
reading from the property again.

To ensure that the property data does not grow indefinitely, Xlib
recycles 21 Atoms in round-robin fashion. Because the XIM specification
does not limit the number of Atom names of the form "_clientXXX" to be
used for data transfer over window properties, an XIM server should be
able to keep of track any number of Atoms, remembering the offset into
each property.

The attached patch implements correct tracking of property offsets.

[Comment 1 klemensbaum 2014-11-26 13:59:44 UTC]

Created attachment 390338 [details, diff]
IMdkit: Track window property offsets correctly

[Comment 2 klemensbaum 2014-11-26 14:02:44 UTC]

Note: As bugzilla does not preserve the filenames, the first patch (https://bugs.gentoo.org/attachment.cgi?id=390336) is intended for ibus and the second one for scim (https://bugs.gentoo.org/attachment.cgi?id=390338).

[Comment 3 Rafał Mużyło 2014-11-27 01:00:50 UTC]

Hey, do you think http://code.google.com/p/ibus/issues/detail?id=1686 (that was closed due to upstream being unable to reproduce) could be related ?

TBH, I don't think it is, but perhaps you've a good idea where that problem could be coming from too.

[Comment 4 Yixun Lan 2014-12-23 10:10:04 UTC]

I'll roll out a patches set which tracking upstream's repository directly, so will also include this fix.

thanks very much, will do in a few days.. (probably tomorrow..)

[Comment 5 Yixun Lan 2014-12-24 01:50:28 UTC]

+*ibus-1.5.9-r1 (24 Dec 2014)
+
+  24 Dec 2014; Yixun Lan <[e-mail]> +ibus-1.5.9-r1.ebuild:
+  bump upstream patches, fix bug 530768. enable USE=vala by default since
+  ui/gtk3/*.vala hae been touched