bug#16737: Timed out waiting for reply from selection owner

["Alan D. Salewski" <salewski@att.net>]

The below cookbook works to reproduce the issue for me every time, so I
can now trigger the issue on-demand.

As noted in message #149 above[0], I'm running the
'emacs24-lucid-24.4+1-5' package on Debian GNU/Linux; x86_64; 4 core
Intel i7.

I'm running an X11 window manager (sawfish) with no clipboard manager.

To reproduce the issue:

    1. $ type -a emacs
       emacs is /usr/bin/emacs

       $ readlink -f /usr/bin/emacs
       /usr/bin/emacs24-lucid

       $ emacs -Q

       The "*scratch*" buffer is visible.

    2. M-x server-start

    3. In a terminal window (xterm in my case):

       $ emacsclient -t

       The "*scratch*" buffer is visible here, as well.

    4. Select a sizable bit of text to the X11 clipboard. A small amount
       of text won't trigger the issue, but I don't yet know what the
       boundary is. For my testing, I have a browser window open to
       this web page in iceweasel (firefox), and use the 'C-a' hotkey in
       that app followed by 'C-c' to select the full page of text:

           http://matt.might.net/articles/low-level-web-in-racket/

    5. In the emacsclient window in the terminal emulator, paste the
       text from the clipboard. I use the middle button on my 3-button
       mouse to do this.

    6. Back in iceweasel, select any small amount of text (~20 chars is
       fine) from the same page (again, using 'C-c').

    7. In the X11 emacs frame, position the mouse pointer over the
       blinking cursor and press the middle mouse button to attempt a
       "paste" operation (mouse-yank-primary).

       Emacs appears to hang for about 20 seconds, and then the "Timed
       out waiting for reply..." message appears.

The cookbook works not only with the stock Debian 'emacs24-lucid'
package, but also with that package compiled with different build time
options (-g, -O0, -DTRACE_SELECTION). The cookbook also works when I
build with random other debugging code compiled in (all based on the
Debian source package emacs24-24.4+1). It does not seem to be sensitive
to being set up "just right".

A slight variation of the above cookbook works with the stock 'emacs24'
Debian package (same version as the '*-lucid' package above), which is
the variation compiled to use gtk. For this version, the small amount of
text selected in step 6 above does not seem to trigger the issue, but
pasting the full amount of text from the web page does. So the cookbook
variation here is to simply skip step 6 (or replace it with step 4, if
some other process has become the X11 selction "owner"). When running
this version, the paste into the X11 emacs frame is preceeded by a pause
and CPU spiking to 100%, the same as indicated by other reports.

Once the issue has been triggered, no further "paste" operations will
work in any emacs X11 frame that is part of the same emacs process, at
least not without using gdb to jump over these lines in
x_get_foreign_selection (xselect.c):

1241    if (NILP (XCAR (reading_selection_reply)))
1242      error ("Timed out waiting for reply from selection owner");

Once those are jumped, the "paste" operation completes (the text shows
up on the buffer, as desired), but the state is still hosed.

Pasting into 'emacsclient -t' buffers running in terminal emulator
windows (xterm) does continue to work, though. So if somebody is truly
desperate to keep a given emacs process alive, keeping a terminal-based
emacsclient window handy as a target for paste operations could serve as
a workaround once the issue has been triggered.

Thanks,
-Al


[0] message #149
    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737#149