GNU bug report logs - #6585
23.1; Hang / CPU 100% on background interaction when in minibuffer

Previous Next

Full log

View this message in rfc822 format

From: "Jason S. Cornez" <jcornez <at> ravenpack.com>
To: 6585 <at> debbugs.gnu.org
Subject: bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer
Date: Thu, 15 Jul 2010 14:05:14 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe I have found the problem.  A custom function to switch to a
buffer is being called.  It looks like...

- ----
(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))))
- ----

Now, if start == (selected-window) is the minibuffer, then it should be
clear that current == (next-window ... 'no-minibuffer ...) will never
result in (eq start current).  And if the buffer that is passed in isn't
visible then (not found) will never be nil and we are stuck in an
infinite loop.

So this part is not an emacs problem at all.  But I am puzzled as to why
if this is byte-compiled I can't C-g and break out of this.

I'll fix my code and then the problem goes away.  So if you want to
consider this "not-a-bug", ok.  But shouldn't C-g work here?

Thanks,
- -Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw++XoACgkQQlm6HDTMLyM0FACgivAX/CS3aQ8GjHguFJmPUoOs
HkwAoOevvsIpPWnEYEHl/By38pnh4DqV
=EHpz
-----END PGP SIGNATURE-----

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.