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

Previous Next

Full log

Message #20 received at 6585 <at> debbugs.gnu.org (full text, mbox):

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

> 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.

Using `next-window' to find all windows is generally unsafe since
windows might get created and deleted in between (in particular the one
you named `start').  Always use `window-list' instead.  The doc-string
of `next-window'

  If you use consistent values for MINIBUF and ALL-FRAMES, you can use
  `next-window' to iterate through the entire cycle of acceptable
  windows, eventually ending up back at the window you started with.

is IMHO misleading in this regard.

> 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?

C-g should work.  If it doesn't we have a bug.  IIUC the only occurrence
of `switch-to-buffer' is ifdefd out in the source code so there can't be
any harm from an inhibit-quitted call from C.  Could you try to run Emacs
in the debugger to find out where it hangs?  Or post a self-contained
emacs -Q based recipe here?

martin

Previous Next

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