GNU bug report logs - #46284
27.1; emacs-27: windows-nt regression with process sentinel's change description argument

Previous Next

Package: emacs;

Reported by: Ioannis Kappas <ioannis.kappas <at> gmail.com>

Date: Thu, 4 Feb 2021 03:27:02 UTC

Severity: normal

Found in version 27.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ioannis Kappas <ioannis.kappas <at> gmail.com>
Cc: 46284 <at> debbugs.gnu.org
Subject: bug#46284: 27.1; emacs-27: windows-nt regression with process sentinel's change description argument Previous Next
Date: Thu, 04 Feb 2021 18:18:47 +0200
> From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
> Date: Thu, 4 Feb 2021 07:36:23 +0000
> 
> It appears as if the underlying signal number to description conversion
> method is broken in emacs-27 on windows-nt causing the regression.
> 
> Looking at the code, it looks like the issue is around the area which
> attempts to convert a signal number to a string description. On emacs
> version prior and including emacs-27, the conversion is done by
> directly accessing the _sys_siglist[] table provided in the unix
> systems, mapping signal numbers to signal descriptions, e.g. SIGINT ->
> "Interrupted". On native windows though, this table does not exist, and
> emacs simulates it in src/sysdep.c:init_signals() so as to conform with
> the rest of the code which expects this table to be there.
> 
> init_signals() only populates the descriptions in the C table when emacs is not
> !initialized, i.e. during the dumping phase. When emacs is thus ran
> normally, it expects this table to have been loaded from the dump into
> memory.
> 
> This table though does not appear to make it through to the dump in
> emacs-27.  Having a look at the new pdumper, it looks like that it
> performs differently than its predecessor. It seems as if it
> only cover lisp constructs, while Unexec was also dumping the data
> section of the process from memory? If true then, it implies that this
> table is not eligible for dumping any more (since it is a C array), but should always be
> initialised when emacs is invoked by the user.  This has a very
> simple solution, taking out the if (!initialized) line in
> src/sysdep.c:init_signals():

Thanks for the analysis and the patch.  I'd prefer to fix this in a
slightly different way, which keeps the support for building Emacs
with unexec.  Does the following patch work for you?

diff --git a/src/sysdep.c b/src/sysdep.c
index f94ce4d..d100a5c 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -1980,7 +1980,8 @@ init_signals (void)
 #endif
 
 #if !HAVE_DECL_SYS_SIGLIST && !defined _sys_siglist
-  if (! initialized)
+  if (! initialized
+      || dumped_with_pdumper_p ())
     {
       sys_siglist[SIGABRT] = "Aborted";
 # ifdef SIGAIO




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

Previous Next


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