Emacs Bug: Pasting into Emacs Freezes Emacs, 2015
there's this bug that started to happen about 2014, Emacs 24, and 25.
- GNU bug report logs - #16737
- From: Sujith Manoharan
- Subject: 24.3.50; Yank causes hang
- Date: Thu, 13 Feb 2014 09:10:55 +0530
Pasting content selected in a browser causes Emacs to hang completely sometimes. This is not consistently reproducible, but it happens after a few hours of usage, sometimes days.
Here's a temp solution. Make the time out small. Then, when the bug happens, it won't freeze emacs, then, you restart emacs.
;; 2015-07-04 bug of pasting in emacs. ;; http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737#17 ;; http://ergoemacs.org/misc/emacs_bug_cant_paste_2015.html (setq x-selection-timeout 300)
This happens to me when i use
on few thousand files.
[see Find Replace in Pure Emacs Lisp xah-find.el].
Not always, but most of the time. The number of files doesn't seem to matter. But what matters is likely the number of replacements.
Here's the bug reproduction steps from the GNU emacs bug track:
From: "Alan D. Salewski" To: 16737 @ debbugs.gnu.org Subject: Re: bug#16737: Timed out waiting for reply from selection owner Date: Sun, 14 Jun 2015 23:00:34 -0400 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, 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  message #149 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737#149