Subject: bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer

From: "Jason S. Cornez" <[email-masked]>
Date: Tue, 31 Aug 2010 08:42:50 +0200

Sorry this has taken so long; I've just been busy with other stuff.

Here is a self-contained test case that shows emacs hanging as I have
described above.  It does seem to depend on the inhibited quitting as
suggested by Johan Bockgård in Msg #26 above.

1. Start a fresh emacs-23.2:  /usr/local/emacs-23.2/src/emacs -q
2. M-x ielm and paste the following function.
(defun my::switch-to-buffer (buffer)
  ;; if buffer is in some window, go to it, otherwise switch-to-buffer
  (let ((start (selected-window))
	(current (next-window (selected-window) 'no-minibuffer 'visible))
	(found nil))
    (while (and (not (eq current start))
		(not found))
      (if (eq buffer (window-buffer current))
	  (setq found current))
      (setq current (next-window current 'no-minibuffer 'visible)))
    (if (null found)
	(switch-to-buffer buffer)
      (select-window found))))
3. (run-at-time 5 nil 'my::switch-to-buffer "*GNU Emacs*")
   [Wait 5 seconds and emacs should switch to the buffer]
4. C-x b *ielm*
5. (run-at-time 5 nil 'my::switch-to-buffer "*GNU Emacs*")
   C-x C-f [do this immediately, before the 5 seconds, then wait]

Once the 5 seconds expires, emacs will be using 100% CPU and will not
respond to C-g.  It is not totally dead, as mouse rollovers (eg. on the
toolbar) seem to work.  But it is in a state where I can't seem to get
it back to being useful again.

Of course, fixing the elisp function is easy and that simply and
effectively avoids this problem.  Still, I find it disconcerting that I
can lockup emacs in such a manner.

Hoping this is helpful.
- -Jason