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

Previous Next

Package: emacs;

Reported by: Baylis Shanks <bshanks3 <at> hotmail.com>

Date: Thu, 21 Sep 2017 17:22:02 UTC

Severity: normal

Tags: fixed

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Baylis Shanks <bshanks3 <at> hotmail.com>
Cc: 28542 <at> debbugs.gnu.org
Subject: bug#28542: Temporary failure in name resolution while quitting emacs
Date: Mon, 30 Nov 2020 11:53:24 +0100
Baylis Shanks <bshanks3 <at> hotmail.com> writes:

> I had an http address open in a buffer (i think i closed that buffer),
> and then i disconnected from the internet and then attempted to quit
> emacs. Emacs would not quit; when i attempted to quit it, a message
> involving 'open-network-stream' and 'temporary failure in name
> resolution' would be displayed in *messages* and then nothing would
> happen.
>
> Manually opening an elisp buffer and using setq to remove
> save-place-kill-emacs-hook from kill-emacs-hook solved the problem.

(This bug report unfortunately got no response at the time.)

I'm guessing you don't have a backtrace here to let us see what the code
in question was after all this time?

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




This bug report was last modified 4 years and 161 days ago.

Previous Next


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