GNU bug report logs - #32487
26.1.50; keyboard-quit while main thread blocked crashes Emacs

Previous Next

Package: emacs;

Reported by: Gemini Lasswell <gazally <at> runbox.com>

Date: Mon, 20 Aug 2018 23:00:01 UTC

Severity: normal

Found in version 26.1.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 32487 <at> debbugs.gnu.org
Subject: bug#32487: 26.1.50; keyboard-quit while main thread blocked crashes Emacs
Date: Tue, 21 Aug 2018 18:22:19 +0300
> From: Gemini Lasswell <gazally <at> runbox.com>
> Date: Mon, 20 Aug 2018 15:57:08 -0700
> 
> In both emacs-26 and master, it's possible to hang or crash Emacs with
> Lisp code which uses threads and is buggy in ways which cause the main
> thread to be blocked, combined with keyboard-quit.

That's ample punishment for a buggy program, don't you think?

> To reproduce, copy the code listed below into a buffer and evaluate it
> (with emacs -Q if you wish).  Then choose one of:
> 
> M-x my-hang-1 RET
> M-x my-hang-2 RET
> M-x my-hang-3 RET
> 
> Result: Emacs will stop responding to keyboard input.  Repeated use of
> C-g will do nothing when running under X11 and will cause Emacs to crash
> when running in a terminal.

Doing nothing is fine when a program is buggy.

On a TTY, the 1st and the 3rd example are not crashes: they are the
"emergency escape" feature of Emacs.  You can read about it in the
manual.  It is triggered when more than one C-g is pressed without
Emacs being able to process the first one.  Due to the way we process
input nowadays, you cannot see this in action except on a Unix TTY,
where C-g triggers a SIGINT.

The 2nd example seems to be caused by a non-main thread entering
redisplay (I think).  Or something like that.




This bug report was last modified 7 years and 18 days ago.

Previous Next


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