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

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

[Jason Cornez]

----
Hello, I am using emacs for lisp programming.  Emacs talks to the lisp
image using sockets; the lisp runs as a subprocess.  If a background
lisp thread enters the lisp debugger, this opens a new buffer in emacs
visible in some window where it is possible to debug the problem.
Usually this all works fine.

However, if I am currently interacting with emacs in the minibuffer at
the time the lisp tries to open the new window, then emacs hangs and
consumes 100% CPU (for one core).  By "iteracting" I simply mean that
the emacs focus is in the minibuffer, such as for C-x C-f.  I don't
need to be actively typing or anything.  That is, the minibuffer is
active.

The emacs process seems to be entirely unresponsive: the cursor stops
blinking, no keyboard input is accepted, the menus do not activate,
sending commands like "emacsclient -e '(abort-recursive-edit)'" just
hang and do nothing.  The only thing I can do is kill the emacs
process.

This is very easy for me to reproduce, and I think it should not be
too hard to replicate my environment.  I also suspect that something
other than the background lisp which also would attempt to communicate
with emacs similarly while the minibuffer is active would have the
same result.  I haven't been able to come up an idea here yet.

1. I use Franz Allegro Common Lisp 8.2 and it communicates with emacs
via ELI (emacs lisp interface, also from Franz).  There is a freely
downloadable trial version of this available. www.franz.com

2. Start emacs and launch the lisp.  This is just a matter of invoking
M-x fi:common-lisp from emacs.  The Franz documentation details this
if interested.

3. At the lisp prompt:
   CL-USER(1): (mp:process-run-function "foo"
                                        (lambda ()
                                          (sleep 5) (break "foo")))

4. Immediately after hitting <Enter> above, then do C-x C-f and just
wait until the 5 seconds expire.  Emacs is now hung as I described
above.  (If you don't activate the minibuffer within 5 seconds, you'll
end up in a new buffer *background-interaction* where you can debug
the lisp process.)

Even though the steps above involve Franz ACL8.2 and ELI, I don't
think the problem is at all specific to this.  If someone can suggest
a more typical way of getting a background/child process to
communicate with emacs asynchronously, I'll be happy to try to
reproduce the problem.

Thank you,
-Jason
----


In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-03-29 on yellow, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Apropos

Minor modes in effect:
  csv-field-index-mode: t
  desktop-save-mode: t
  display-time-mode: t
  partial-completion-mode: t
  diff-auto-refine-mode: t
  xterm-mouse-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
d SPC t h i s SPC c a u s e s SPC <backspace> <backspace> 
d SPC p r i n t - t o M-/ <help-echo> <backspace> <backspace> 
a s <backspace> s - x m n <backspace> l SPC t o SPC 
g e t SPC c o n f u s e d . SPC SPC A l s o SPC n e 
e d e d SPC t o SPC f i x SPC u p SPC t h e SPC d e 
b u g g i n g SPC c o d e SPC i n SPC e v e M-/ SPC 
a l o n g SPC t h e SPC w a y . <down> C-c C-c g <switch-frame> 
C-c r M-x t o g g e l <backspace> <backspace> l e - 
f o <tab> C-g M-x f o n t <tab> <tab> l <tab> m <tab> 
<return> <down> <down> <down> <down> <down> <down> 
<down> M-x f o n t - l o <tab> m <tab> <return> <up> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <up> <down> <down> <down> <down> <down> <up> 
<end> <down> <down> <down> <down> <down> <down> <down> 
<up> <left> <left> <left> <left> <left> <right> <right> 
<right> <right> <right> <right> <right> <up> <up> <up> 
<up> C-x C-f e - n <tab> <return> C-x k <return> C-x 
C-f M-p <return> <up> <up> <up> <up> <up> <end> <up> 
<up> <down> <down> <down> <switch-frame> <f5> M-x e 
m - r <tab> <M-backspace> <M-backspace> b u <tab> g 
<tab> <tab> C-g <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> C-h a b u g <return> 
C-x o C-x 1 M-> <prior> <prior> <prior> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
Expansion found in '*magit: ravenpack*'
Git finished.
package specification is `com.ravenpack.news.classification'
Quit
Font-Lock mode disabled
Font-Lock mode enabled
package specification is `com.ravenpack.news.classification'
Quit
Type C-x 1 to remove help window.  
Mark set

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

[Eli Zaretskii]

> Date: Thu,  8 Jul 2010 16:19:06 +0200 (CEST)
> From: jcornez@ravenpack.com (Jason Cornez)
> Cc: 
> 
> However, if I am currently interacting with emacs in the minibuffer at
> the time the lisp tries to open the new window, then emacs hangs and
> consumes 100% CPU (for one core).  By "iteracting" I simply mean that
> the emacs focus is in the minibuffer, such as for C-x C-f.  I don't
> need to be actively typing or anything.  That is, the minibuffer is
> active.
> 
> The emacs process seems to be entirely unresponsive: the cursor stops
> blinking, no keyboard input is accepted, the menus do not activate,
> sending commands like "emacsclient -e '(abort-recursive-edit)'" just
> hang and do nothing.  The only thing I can do is kill the emacs
> process.

You can help debugging this if you attach GDB to Emacs when it hangs
like that, and see where it is looping.  The file etc/DEBUG in the
Emacs source tree has some advice how to debug these problems, under
"If the symptom of the bug is that Emacs fails to respond".

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

[Jason S. Cornez]

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

I'm running the emacs23 that comes with k/unbuntu.  I didn't build it
myself and it apparently doesn't have debugging info in the image.  And
so what follows may not be so helpful.  But none the less this is the
gdb session.  You can see the ^Z at every point where emacs was failing
to respond.

I suppose I'll have to build my own emacs to be able to provide anything
further that might be helpful.  I'd just like to confirm that this
doesn't sound familiar to anyone.  And maybe someone has a suggestion
for a more common-place scenario that might trigger this (rather than my
steps to reproduce which involve Allegro Common Lisp).

- -Jason

$ gdb emacs
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/emacs...(no debugging symbols
found)...done.(gdb) run
Starting program: /usr/bin/emacs
[Thread debugging using libthread_db enabled]
^Z
Program received signal SIGTSTP, Stopped (user).
0x000000000058bef9 in ?? ()
(gdb) step
Cannot find bounds of current function
(gdb) finish
Run till exit from #0  0x000000000058bef9 in ?? ()

Program received signal SIGTSTP, Stopped (user).
0x000000000058bef9 in ?? ()
(gdb) finish
Run till exit from #0  0x000000000058bef9 in ?? ()
^Z
Program received signal SIGTSTP, Stopped (user).
0x000000000058b3c6 in ?? ()
(gdb) finish
Run till exit from #0  0x000000000058b3c6 in ?? ()

Program received signal SIGTSTP, Stopped (user).
0x000000000058b3c6 in ?? ()
(gdb) finish
Run till exit from #0  0x000000000058b3c6 in ?? ()
^Z
Program received signal SIGTSTP, Stopped (user).
0x000000000058befe in ?? ()
(gdb) finish
Run till exit from #0  0x000000000058befe in ?? ()

Program received signal SIGTSTP, Stopped (user).
0x000000000058befe in ?? ()
(gdb) next
Cannot find bounds of current function
(gdb) finish
Run till exit from #0  0x000000000058befe in ?? ()
^Z
Program received signal SIGTSTP, Stopped (user).
0x0000000000553ef2 in ?? ()
(gdb)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw2ypIACgkQQlm6HDTMLyM44ACfTagZPEy6x3v5IOTOKNJ6EEvI
Q4oAoJb3LUYmcbdtM2FQN0NFEAPXS1Ll
=k0I5
-----END PGP SIGNATURE-----

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

[Jason S. Cornez]

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

I've built emacs 23.2 (using
http://ftp.gnu.org/pub/gnu/emacs/emacs-23.2.tar.bz2) on my system and I
can still reproduce the non-responsive behavior.  Here is the gdb session.

- ----
$ gdb ./emacs
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/emacs-23.2/src/emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :0.0
TERM = xterm-256color
Breakpoint 1 at 0x4d5cd0: file emacs.c, line 431.
Temporary breakpoint 2 at 0x4f6510: file sysdep.c, line 1129.
(gdb) run
Starting program: /usr/local/emacs-23.2/src/emacs
[Thread debugging using libthread_db enabled]
^Z
Program received signal SIGTSTP, Stopped (user).
Fbyte_code (bytestr=11586322, vector=11586322, maxdepth=<value optimized
out>) at bytecode.c:494
494               op = op - Bvarref;
(gdb) step
495               goto varref;
(gdb) finish
Run till exit from #0  Fbyte_code (bytestr=11586322, vector=11586322,
maxdepth=<value optimized out>) at bytecode.c:495
^Z
Program received signal SIGTSTP, Stopped (user).
0x0000000000589af0 in Fbyte_code (bytestr=11586322, vector=0,
maxdepth=<value optimized out>) at bytecode.c:506
506                 if (SYMBOLP (v1))
(gdb) finish
Run till exit from #0  0x0000000000589af0 in Fbyte_code
(bytestr=11586322, vector=0, maxdepth=<value optimized out>) at
bytecode.c:506
^Z
Program received signal SIGTSTP, Stopped (user).
0x00000000005884c3 in Fbyte_code (bytestr=13023440, vector=0,
maxdepth=<value optimized out>) at bytecode.c:482
482           switch (op)
(gdb) next
660               op -= Bcall;
(gdb) next
664                 DISCARD (op);
(gdb) next
663                 BEFORE_POTENTIAL_GC ();
(gdb) next
680                 TOP = Ffuncall (op + 1, &TOP);
(gdb) next
664                 DISCARD (op);
(gdb) next
680                 TOP = Ffuncall (op + 1, &TOP);
(gdb) next
681                 AFTER_POTENTIAL_GC ();
(gdb) next
680                 TOP = Ffuncall (op + 1, &TOP);
(gdb) next
681                 AFTER_POTENTIAL_GC ();
(gdb) next
682                 break;
(gdb) next
479           op = FETCH;
(gdb) next
482           switch (op)
(gdb) next
479           op = FETCH;
(gdb) next
482           switch (op)
(gdb) next
617                 v1 = TOP;
(gdb) next
618                 PUSH (v1);
(gdb) next
619                 break;
(gdb) next
479           op = FETCH;
(gdb) next
482           switch (op)
(gdb) next
479           op = FETCH;
(gdb) next
482           switch (op)
(gdb) next
581               op -= Bvarset;
(gdb) next
582               goto varset;
(gdb) next
594                 sym = vectorp[op];
(gdb) next
595                 val = TOP;
(gdb) next
594                 sym = vectorp[op];
(gdb) next
598                 if (SYMBOLP (sym)
(gdb) next
600                     && !XSYMBOL (sym)->indirect_variable
(gdb) next
598                 if (SYMBOLP (sym)
(gdb) next
602                     && !MISCP (XSYMBOL (sym)->value))
(gdb) next
603                   XSYMBOL (sym)->value = val;
(gdb) next
598                 if (SYMBOLP (sym)
(gdb) next
611               (void) POP;
(gdb) next
612               break;
(gdb) next
479           op = FETCH;
(gdb) next
482           switch (op)
(gdb)
- ----

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

iEYEARECAAYFAkw9kSIACgkQQlm6HDTMLyNG/wCg0bNiDVpr7WziKA2aJvrgNOF4
OuoAnjh8/xNHb8USr9JTjgv6+sxmRzX1
=yHME
-----END PGP SIGNATURE-----

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

[Jason S. Cornez]

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

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

[martin rudalics]

 > 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

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

[Jason S. Cornez]

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

Thanks Martin,

The debugger run is posted above.  If I have more time I can try to make
a test case.  I think it should be enough to define the function I did
and byte-compile it.  Then make emacs be waiting with the minibuffer
active.  Then from a terminal:

  emacsclient -e '(my::switch-to-buffer "buffer")'

That's almost certainly not exactly correct and I haven't tried it, but
it's the basic idea.

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

iEYEARECAAYFAkw/KmEACgkQQlm6HDTMLyOdeQCfZOYNZQXjc299L7jzzdhiict9
qpgAn1zEnJr34lf4on7oO5thHmw6YSgA
=qPMc
-----END PGP SIGNATURE-----

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

[martin rudalics]

 >   emacsclient -e '(my::switch-to-buffer "buffer")'
 >
 > That's almost certainly not exactly correct and I haven't tried it, but
 > it's the basic idea.

It's still a mystery to me why this should happen only when you
byte-compile my::switch-to-buffer.

martin

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

[Jason S. Cornez]

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

On 07/16/2010 10:27 AM, martin rudalics wrote:
>>   emacsclient -e '(my::switch-to-buffer "buffer")'
>>
>> That's almost certainly not exactly correct and I haven't tried it, but
>> it's the basic idea.
> 
> It's still a mystery to me why this should happen only when you
> byte-compile my::switch-to-buffer.
> 
> martin

I apologize, that is an assumption which I didn't test.  I do know that
when I edebug the function (C-u C-M-x) then I can use C-g.  And I could
see gdb that emacs was stuck in bytecode.c.  So I made the leap to byte
compiled being part of the problem.

Sorry for jumping to that conclusion.  In truth I don't know if
byte-compiling the function matters or not.

And I still haven't had a chance to work on a stand-alone test case.
Given that my own specific problem is resolved, I've mostly moved on.
But if I find the time to help some more, I'll post what I find.  Even
if that is just to say that I can't isolate the problem.

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

iEYEARECAAYFAkxAGtMACgkQQlm6HDTMLyNZRgCfaV62a7Hk+W3ROFXVFoRqSaah
rZoAnRPf251n9B+Bbfh6Aa0MuE2YuHyD
=g5Yn
-----END PGP SIGNATURE-----

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

[Johan Bockgård]

"Jason S. Cornez" <jcornez@ravenpack.com> writes:

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

Note that quitting is inhibited for code that runs from timers or
process filters etc. (I don't know if this is your problem.)

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

[Jason S. Cornez]

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

On 07/15/2010 05:53 PM, Johan Bockgård wrote:
> Note that quitting is inhibited for code that runs from timers or
> process filters etc. (I don't know if this is your problem.)

I've fully explained the situation above.  The message which does
initiate the elisp function with the infinite loop does come from an
external process.  So while there is obviously a bug in the elisp code
(which I've now fixed) the resulting non-responsive emacs consuming the
CPU seems like a bad thing and I really think I ought to be able to quit
from this situation - indeed that I ought to be able to quit from just
about any situation.

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

iEYEARECAAYFAkw/MGUACgkQQlm6HDTMLyPNXQCg6B/4WdyNIOxu/axl5mg4m6jv
eFoAoPVsDn0RQ1ncsQuSCm+oYxE/AkWP
=+AsD
-----END PGP SIGNATURE-----

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

[Jason S. Cornez]

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

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

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

iEYEARECAAYFAkx8pGoACgkQQlm6HDTMLyO2OQCfXinWQlQ/EeYlhOdoSQGlQ7pq
OKUAoLwpSxsEThEkn4mPpZk9PlOkNsOy
=iq6n
-----END PGP SIGNATURE-----

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

[Stefan Monnier]

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

All code run from timers and from (post|pre)-command-hook (as well as
jit-lock, filters, and a few other things) is run with inhibit-quit set
to t because the user may not know this code is running so if she hits
C-g it "probably" means she wants to interrupt something else.

It's not broken.  Basically, the problem is in your code: such async
code should not run for indefinite amount of time, whereas your code may
inf-loop.

2 solutions:
- fix your code so it doesn't inf-loop (usually the best solution).
- wrap your code in with-local-quit to let C-g interrupt it.

Admittedly, Emacs should also additionally understand something like C-g
C-g C-g C-g as a sign that the user is getting impatient and we should
thus ignore the inhibit-quit flag.  But such a case is always a sign of
a bug somewhere.


        Stefan

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

[Jason S. Cornez]

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

Yes, I agree about fixing the elisp code - indeed this has been done.
But what about when the code isn't mine, but is in some library I happen
to be using?  Again, the right solution is always to fix the code, but
that might not be possible for the end user of emacs to do.

But I find it difficult to accept that emacs gets wedged like it does. I
love emacs and having to kill the process from the OS is just so, so
sad.  I would love a C-g C-g C-g option (just like there is ESC ESC
ESC).  And it would be even better if this could work in conjunction
with some flag so that it pops me into the debugger and I can see what
function I've broken out of.

So again, I know the elisp code was broken.  But I still say that emacs
is broken since it is currently impossible to salvage the situation.
Yes, it is a sign of a bug somewhere - and I want emacs to help me find
it, or at least escape from it.

Thanks for your consideration,
- -Jason

On 08/31/2010 12:24 PM, Stefan Monnier wrote:
>> 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.
> 
> All code run from timers and from (post|pre)-command-hook (as well as
> jit-lock, filters, and a few other things) is run with inhibit-quit set
> to t because the user may not know this code is running so if she hits
> C-g it "probably" means she wants to interrupt something else.
> 
> It's not broken.  Basically, the problem is in your code: such async
> code should not run for indefinite amount of time, whereas your code may
> inf-loop.
> 
> 2 solutions:
> - fix your code so it doesn't inf-loop (usually the best solution).
> - wrap your code in with-local-quit to let C-g interrupt it.
> 
> Admittedly, Emacs should also additionally understand something like C-g
> C-g C-g C-g as a sign that the user is getting impatient and we should
> thus ignore the inhibit-quit flag.  But such a case is always a sign of
> a bug somewhere.
> 
> 
>         Stefan

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

iEYEARECAAYFAkx82rYACgkQQlm6HDTMLyPZZwCgu6ONheghjKDSYg0Ra5j0+rFt
EPYAoNR1225PzzmNFl34bgThRGijd/HW
=bUAm
-----END PGP SIGNATURE-----

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

[Stefan Monnier]

> sad.  I would love a C-g C-g C-g option (just like there is ESC ESC
> ESC).  And it would be even better if this could work in conjunction
> with some flag so that it pops me into the debugger and I can see what
> function I've broken out of.

100% agreement.  Patch welcome,


        Stefan

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

[Jason S. Cornez]

On 08/31/2010 03:09 PM, Stefan Monnier wrote:
> 100% agreement.  Patch welcome,
> 
> 
>         Stefan

How about something like this...
----8<----
src/keyboard.c /usr/local/emacs-23.2/src/keyboard.c
*** src/keyboard.c      2010-04-04 00:26:07.000000000 +0200
--- /usr/local/emacs-23.2/src/keyboard.c        2010-08-31
17:03:14.648740153 +0200
*************** interrupt_signal (signalnum)    /* If we do
*** 11122,11127 ****
--- 11122,11136 ----
    errno = old_errno;
  }

+
+ /* JSC: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6585 */
+
+ /* If emacs is stuck because `inhibit-quit' is true, then keep track
+    of the number of times C-g has been requested.  If C-g is pressed 3
+    times, then quit anyway.  If `debug-on-quit' is true, then it is
+    honored when the quit occurs after the third C-g. */
+ static int force_quit_count;
+
  /* This routine is called at interrupt level in response to C-g.

     It is called from the SIGINT handler or kbd_buffer_store_event.
*************** handle_interrupt ()
*** 11239,11246 ****
          UNGCPRO;
        }
        else
!       /* Else request quit when it's safe */
!       Vquit_flag = Qt;
      }

  /* TODO: The longjmp in this call throws the NS event loop integration
off,
--- 11248,11266 ----
          UNGCPRO;
        }
        else
!         {
!           /* Else request quit when it's safe */
!           if (NILP (Vquit_flag))
!             {
!               force_quit_count = 0;
!             }
!         if (++force_quit_count == 3)
!             {
!               immediate_quit = 1;
!               Vinhibit_quit = Qnil;
!             }
!           Vquit_flag = Qt;
!         }
      }

  /* TODO: The longjmp in this call throws the NS event loop integration
off,
----8<----

This does indeed solve the problem for me.  But I freely admit that I've
never done emacs development before and so something more may be
required or desired.  Anyway, this is certain a start and I hope it helps.

Best,
-Jason

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

[Stefan Monnier]

> How about something like this...

Thank you, installed,


        Stefan

bug#6585: Patch welcome?

[Jason S. Cornez]

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

Hi. Just wanted to see if something else was requested from me here.

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

iEYEARECAAYFAkyOJZAACgkQQlm6HDTMLyOmygCgzdsQJ2CyvxZRZvYPyJpbPwe9
brsAnjQpmYIJZz2b8Nuf2YhtiFQGX4e2
=Aza0
-----END PGP SIGNATURE-----

bug#6585: Patch welcome?

[Stefan Monnier]

> Hi.  Just wanted to see if something else was requested from me here.

Not yet, no.  I haven't had time to look into your patch yet.
Thanks already for submitting it, tho.


        Stefan

bug#6585: status of patch?

[Tim Connors]

>> Hi.  Just wanted to see if something else was requested from me here.
>
>Not yet, no.  I haven't had time to look into your patch yet.
>Thanks already for submitting it, tho.
>
>        Stefan

Just a vote for this or a similar patch.  After years of mounting
frustration with xemacs, I finally ported my elisp files back to emacs and
started using it regularly last week.  Almost immediately I came across a
problem where yank or just leaving the emacs session sit overnight would
result in emacs chewing 100% cpu.  It appears a font-locked buffer was
stuck in an infinite loop (unkillable, and this would make sense given
that font-loick is invoked from a timer).  Somehow I seem to have fixed
that, but maybe I just haven't waited long enough for it to reappear.
The obvious C-g C-g C-g would have certainly saved a few
kill-and-restarts.

-- 
Tim Connors

bug#6585: status of patch?

[Stefan Monnier]

>>> Hi.  Just wanted to see if something else was requested from me here.
>> Not yet, no.  I haven't had time to look into your patch yet.
>> Thanks already for submitting it, tho.
> Just a vote for this or a similar patch.  After years of mounting

Duh!  I dropped the ball, didn't I?  Now it's too late for 24.1
To try and reduce the pain, here's what I can give you:
- I looked at the patch and it looks pretty good (i.e. I think it'd be
  acceptable for Emacs-24.2).
- Emacs-24.1 comes with `debug-on-event' which is a similar feature
  (except you need to "kill -USR2 <emacspid>" instead of hitting C-g
  with anger).
- I've just installed a patch in server.el which I believe should
  resolve the OP's original problem.

        Stefan

bug#6585: status of patch?

[Jason S. Cornez]

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

Glad to hear that patch looks good and may make it to a future release.

Thanks,
- -Jason

On 11/22/2011 10:47 PM, Stefan Monnier wrote:
>>>> Hi.  Just wanted to see if something else was requested from
>>>> me here.
>>> Not yet, no.  I haven't had time to look into your patch yet. 
>>> Thanks already for submitting it, tho.
>> Just a vote for this or a similar patch.  After years of
>> mounting
> 
> Duh!  I dropped the ball, didn't I?  Now it's too late for 24.1 To
> try and reduce the pain, here's what I can give you: - I looked at
> the patch and it looks pretty good (i.e. I think it'd be acceptable
> for Emacs-24.2). - Emacs-24.1 comes with `debug-on-event' which is
> a similar feature (except you need to "kill -USR2 <emacspid>"
> instead of hitting C-g with anger). - I've just installed a patch
> in server.el which I believe should resolve the OP's original
> problem.
> 
> Stefan

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

iEYEARECAAYFAk7MmoEACgkQQlm6HDTMLyNajgCfZX7fX3xKsOpk+fbmy+yIZBGz
AbEAoPRudUzORCyM1b9C7/vplWdgm1NV
=RzwN
-----END PGP SIGNATURE-----