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

[Stefan Monnier]

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

Thanks.  Sadly, the developer who was most familiar with this code has
moved on to better pastures, so hopefully someone else will step up
soon, but don't be surprised if your bug doesn't get the attention it
deserves,


        Stefan


> 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