Bug reports for GNU Emacs, the Swiss army knife of text editors

Glenn Morris | 25 Jun 2012 09:21

bug#11724: 24.1; emacs freeze (full hang, ctrl+G or kill -15 do not help) on rope lucky assist


Alex V. Koval wrote (on Mon, 25 Jun 2012 at 07:15 +0300):

> Yes, I pretty well understand that point. 
> 
> But why emacs 24 hangs completely without reacting
> to C-g and other keys? I consider *this* to be emacs bug because it
> makes it impossible for me to debug the problem on Lisp level to
> properly report it to package maintainers as you suggest. 

I don't know, but I could imagine it being unavoidable in some cases
(like the perennial hanging NFS mount scenario, although that's not
the same thing I guess). We should keep the bug-list cc'd since
someone there may have an answer...

The doc of accept-process-output does say that it does not return
until there is some output. It doesn't mention quitting being
inhibited though. By experiment, it is not:

(setq proc (start-process "sleep" nil "sleep" "60"))

(accept-process-output proc)  ; C-g works fine

So I guess you may need to figure out exactly what the relevant
process is and what it is doing.

headers

Stefan Monnier | 25 Jun 2012 16:51

bug#11724: 24.1; emacs freeze (full hang, ctrl+G or kill -15 do not help) on rope lucky assist

>> Yes, I pretty well understand that point. 
>> But why Emacs 24 hangs completely without reacting
>> to C-g and other keys?

Because there are situations where Emacs temporarily inhibits C-g.
These are situations where using accept-process-output without a timeout
is fundamentally a bug (it currently doesn't signal an error in those
cases, but it does output a warning message).

>> I consider *this* to be emacs bug because it makes it impossible for
>> me to debug the problem on Lisp level to properly report it to
>> package maintainers as you suggest. 

In Emacs-24, you can set `debug-on-event' to `sigusr1' after which
sending a SIGUSR1 signal to the process will put you in the
Elisp debugger.

> until there is some output. It doesn't mention quitting being
> inhibited though. By experiment, it is not:

Quit is inhibitted while running pre/post-command-hook, timers, process
filters and sentinels, jit-lock, and probably a few more similar cases.

The general rule is that it's inhibited when running code "behind the
back of the user", so that the user won't accidentally interrupt that
code if she hits C-g for some other reason (e.g. to get out of
a minibuffer).

        Stefan

(Continue reading)