Hm, this is vexing. I am running Ubuntu 14.04, with no unusual Xorg
PPAs.
I did some more testing on my own, and here's what I discovered:
I can essentially only reproduce the bug using urxvt + xmonad as
the window manager. However,
1. If I gksu urxvt (to any user besides the current user), the bug goes away
2. If I nest xmonad inside Xephyr on lightdm, the bug goes away
3. If I compile CVS HEAD rxvt-unicode without XIM support,
the bug goes away
When I compile a debugging build of rxvt-unicode and have it hang, this
is the backtrace it's usually stuck here:
(gdb) bt
#0 0x00007ffff6452c50 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff5a6cb72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007ffff5a6e64f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff7180198 in _XReadEvents (dpy=dpy@entry=0x778b70) at
../../src/xcb_io.c:401
#4 0x00007ffff7168751 in XIfEvent (dpy=0x778b70,
event=event@entry=0x7fffffffc4b0, predicate=predicate@entry=0x7ffff71ae790
<_CheckCMEvent>, arg=arg@entry=0x7d49c0 "\200eG\367\377\177") at
../../src/IfEvent.c:68
#5 0x00007ffff71aef24 in _XimXRead (im=0x7d49c0, recv_buf=0x7fffffffd0e0 "",
buf_len=2048, ret_len=0x7fffffffc5dc) at
../../../../modules/im/ximcp/imTrX.c:476
#6 0x00007ffff71afb80 in _XimReadData (im=im@entry=0x7d49c0,
len=len@entry=0x7fffffffc63e, buf=buf@entry=0x7fffffffd0e0 "",
buf_size=buf_size@entry=2048) at ../../../../modules/im/ximcp/imTransR.c:165
#7 0x00007ffff71afe71 in _XimRead (im=im@entry=0x7d49c0,
len=len@entry=0x7fffffffc6ee, buf=buf@entry=0x7fffffffd0e0 "",
buf_size=buf_size@entry=2048, predicate=predicate@entry=0x7ffff719dc00
<_XimSetICValuesCheck>, arg=arg@entry=0x7efc40 " eG\367\377\177") at
../../../../modules/im/ximcp/imTransR.c:235
#8 0x00007ffff719e8a6 in _XimProtoSetICValues (xic=0x7efc40, arg=<optimized
out>) at ../../../../modules/im/ximcp/imDefIc.c:778
#9 0x00007ffff718cb3d in XSetICValues (ic=0x7efc40) at
../../../src/xlibi18n/ICWrap.c:332
#10 0x000000000042a97f in rxvt_term::im_send_spot (this=this@entry=0x76b2d0) at
main.C:1271
#11 0x000000000041df89 in rxvt_term::flush (this=0x76b2d0) at command.C:1009
#12 0x00000000004406f0 in ev_invoke_pending () at ./../libev/ev.c:3088
#13 0x000000000044191e in ev_run (flags=<optimized out>) at ./../libev/ev.c:3488
#14 0x0000000000416ec3 in main (argc=1, argv=0x7fffffffdbd8) at rxvt.C:38
Frame #4 never returns, but I'm not really sure how to tell why because
this is going through Xim.
Edward
Excerpts from Marc Lehmann's message of 2014-11-25 12:22:15 -0800:
> On Mon, Nov 24, 2014 at 07:56:23PM -0800, "Edward Z. Yang" <[email protected]>
> wrote:
> > program was plover). Below the fold is a test program which pretty
> > reliably hangs rxvt-unicode (you'll need python-xlib). Can anyone else
> > try to reproduce?
>
> When I (or the other people I asked) run it I, I get a few "as" as output,
> and thats it.
>
> In any case, I doubt very much that this is something in urxvt - are you,
> by chance, running gentoo, some experimental unstable x release, buggy
> xtest extensionor another program (e.g. buggy input method) that might
> cause this?
>
> Especially when you see reordered keyboard input the cause would almost by
> guarantee be something else (kernel bug, x bug), as urxvt handles events
> in the order it receives them.
>
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
