GNU bug report logs - #28542
Temporary failure in name resolution while quitting emacs

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: bshanks3 <at> hotmail.com, 28542 <at> debbugs.gnu.org
Subject: Re: bug#28542: Temporary failure in name resolution while quitting
 emacs
Date: Mon, 30 Nov 2020 18:21:52 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 30 Nov 2020 11:53:24 +0100
> Cc: 28542 <at> debbugs.gnu.org
> 
> > 2) more importantly, if there is an error in something called from
> > kill-emacs-hook, emacs should not just return to normal functioning
> > (without quitting), but rather should give the user a choice of
> > whether to continue to quit or not (if continue to quit is chosen, the
> > remaining items in kill-emacs-hook should be called). It's really
> > frustrating to a user when the user cannot figure out how to quit a
> > program.
> 
> I agree.  To reproduce:
> 
> (push (lambda () (error "this is an error")) kill-emacs-hook)
> `C-x C-c'
> 
> Result: Just an error message, and you can't kill Emacs.  I think it
> should catch the error and ask whether to continue anyway.  Opinions?

The ELisp manual says ab out kill-emacs-hook:

     Because ‘kill-emacs’ can be called in situations where user
     interaction is impossible (e.g., when the terminal is
     disconnected), functions on this hook should not attempt to
     interact with the user.  If you want to interact with the user when
     Emacs is shutting down, use ‘kill-emacs-query-functions’, described
     below.

So I don't think we can safely ask whether to continue.  We could
either use safe_run_hooks, as we do in the noninteractive case (thus
silently ignoring errors in this hook even if we do have a means to
communicate with the user), or maybe move the offending function to
kill-emacs-query-functions.  Or try a more limited solution of
ensuring this particular function doesn't signal an error, or catches
it and returns.

> The flow control here is a bit odd, though.  `save-buffers-kill-emacs'
> calls Fkill_emacs, which starts:
> 
> DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P",
> [...]
>   /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
>      set.  */
>   waiting_for_input = 0;
>   if (noninteractive)
>     safe_run_hooks (Qkill_emacs_hook);
>   else
>     run_hook (Qkill_emacs_hook);
> 
> Is this bit done from the C level because of that waiting_for_input
> setting?  And...  I don't understand the comment -- the `error' (which
> calls signal?) doesn't abort Emacs?  Anybody?

I think the comment has this exact scenario in mind: if we don't make
sure waiting_for_input is zero, and the hook just happens to signal an
error, Emacs will dump core.

Previous Next

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