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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Ioannis Kappas <ioannis.kappas@HIDDEN>; dated Thu, 4 Feb 2021 03:27:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 46284 <at> debbugs.gnu.org:


Received: (at 46284) by debbugs.gnu.org; 4 Feb 2021 16:18:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 04 11:18:54 2021
Received: from localhost ([127.0.0.1]:42101 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l7hLK-000679-CS
	for submit <at> debbugs.gnu.org; Thu, 04 Feb 2021 11:18:54 -0500
Received: from eggs.gnu.org ([209.51.188.92]:44152)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1l7hLI-00066v-Qh
 for 46284 <at> debbugs.gnu.org; Thu, 04 Feb 2021 11:18:53 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:39794)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1l7hLD-00039t-Ig; Thu, 04 Feb 2021 11:18:47 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2641
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1l7hLC-0007dm-Ps; Thu, 04 Feb 2021 11:18:47 -0500
Date: Thu, 04 Feb 2021 18:18:47 +0200
Message-Id: <83h7mrrel4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ioannis Kappas <ioannis.kappas@HIDDEN>
In-Reply-To: <CAMRHuGA5cDbcOKdondfxMQLU0nzZ-q_4MFs7ab1SOqcS2DTSrg@HIDDEN>
 (message from Ioannis Kappas on Thu, 4 Feb 2021 07:36:23 +0000)
Subject: Re: bug#46284: 27.1;
 emacs-27: windows-nt regression with process sentinel's change
 description argument Previous Next
References: <CAMRHuGB9j3ZT9oW=0T17+RyVBHa5F8LqWSOYkx=kV5LibF+iAg@HIDDEN>
 <CAMRHuGA5cDbcOKdondfxMQLU0nzZ-q_4MFs7ab1SOqcS2DTSrg@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46284
Cc: 46284 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Ioannis Kappas <ioannis.kappas@HIDDEN>
> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46284; Package emacs. Full text available.

Message received at 46284 <at> debbugs.gnu.org:


Received: (at 46284) by debbugs.gnu.org; 4 Feb 2021 07:36:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 04 02:36:42 2021
Received: from localhost ([127.0.0.1]:39561 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l7ZBy-0007RY-2n
	for submit <at> debbugs.gnu.org; Thu, 04 Feb 2021 02:36:42 -0500
Received: from mail-oo1-f42.google.com ([209.85.161.42]:33391)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1l7ZBv-0007RF-L2
 for 46284 <at> debbugs.gnu.org; Thu, 04 Feb 2021 02:36:40 -0500
Received: by mail-oo1-f42.google.com with SMTP id u7so552723ooq.0
 for <46284 <at> debbugs.gnu.org>; Wed, 03 Feb 2021 23:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=dea26GSkQLUBd6AIg7gSFl8L3k4+B5+jDwowd6O4h5E=;
 b=bmauroplCK4ZJHuY/HgM2SW/bOkI7EIivKDjrBBMRXUCPv4rGWTanjRyJvbggnNQ1s
 apm2rJtT83NjAncR1zg26XjP1OauyUizYjTcc8wMmVBt37QfCp34te8MlDSzHzwkyWr0
 Iiw+JXPzcdF+Dpeo4HgmI99fYSD8WZZk8LqJhuDD0hPCuLsKA9A2LPmaEY9s6P7yxrde
 El4Fmg2lIM5b/2s2dr0FVzTxFToJR8rmB1A9Lk3HU/lt+aTkazFiFIvwLzvqhf/4vicV
 FAMeWilB2l490q9a4bTX3zg2aMLEJq2zVVifuwEk8LOuRWCQc1SAK2RDuREH9C00xyiN
 yVVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=dea26GSkQLUBd6AIg7gSFl8L3k4+B5+jDwowd6O4h5E=;
 b=ekdUYmAupGtD/t8IArs8PKkY4c8gTUVpKzz/SkZDSdRFnsBOZDX8rEzDjz0EwB/uVJ
 VyuIF/xsdl5bU2cCbLFvXVCv3cr9XKD2h6sybQlVr04gZqtV46+sYAFahUETEylhdJ4V
 5L8I6qQaYUwF8MkIm9OdGmfyXsWw7rkaRqog/xhTDD5ck/Ymhgi8ZqXxa2xG64Vxv8Te
 P0MCxqTR/QzSGCU27gHNwmxUTcpWalh3ertldX22MpPqHbn9wBeindIKHCupajK0jLsd
 RuQ8u0TQlufvQx3utIUATz97VBTaYuBkQExotVoyoub1Py4iapu5S99XPbkCZ4JSB9M5
 1YWg==
X-Gm-Message-State: AOAM533d5nKeugwSi56wGhczD1XpENOxiut3HCrQgVyvE79roImVIO5p
 je1AYvAQoZSuakDQCZDNPjhbDEyaVlJFuItmDdb/RjBXb3Scqg==
X-Google-Smtp-Source: ABdhPJzXBhaMGlod7aBsodmUw7cn3IhFvXzCs1YlgAi/mk6TsZW2R3A//UNv4i0V5wPLMiyZXERU8LJwn7WFS8dYIk0=
X-Received: by 2002:a4a:d30d:: with SMTP id g13mr4868817oos.54.1612424193936; 
 Wed, 03 Feb 2021 23:36:33 -0800 (PST)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Thu, 4 Feb 2021 07:36:23 +0000
Message-ID: <CAMRHuGA5cDbcOKdondfxMQLU0nzZ-q_4MFs7ab1SOqcS2DTSrg@HIDDEN>
Subject: 27.1; emacs-27: windows-nt regression with process sentinel's change
 description argument Previous Next
To: 46284 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="0000000000004e8fef05ba7dc39c"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 46284
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000004e8fef05ba7dc39c
Content-Type: text/plain; charset="UTF-8"

Analysis of the issue

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():

diff --git a/src/sysdep.c b/src/sysdep.c
index f94ce4d492..5b4ec68e6b 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -1980,7 +1980,6 @@ init_signals (void)
 #endif

 #if !HAVE_DECL_SYS_SIGLIST && !defined _sys_siglist
-  if (! initialized)
     {
       sys_siglist[SIGABRT] = "Aborted";
 # ifdef SIGAIO

The ert test attached to this bug report then passes.

The above is not an issue in emacs-28 because the conversion from
signal number to description is delegated to Gnulib with Paul Eggert's
df589d36817a8804d67f133890b2f453aefdf3c1 "Simplify by using Gnulib
sigdescr_np module" commit.

--0000000000004e8fef05ba7dc39c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Analysis of the issue<di=
v><br></div><div><div>It appears as if the underlying signal number to desc=
ription conversion</div><div>method is broken in emacs-27 on windows-nt cau=
sing the regression.</div><div><br></div><div>Looking at the code, it looks=
 like the issue is around the area which</div><div>attempts to convert a si=
gnal number to a string description. On emacs</div><div>version prior and i=
ncluding emacs-27, the conversion is done by</div><div>directly accessing t=
he _sys_siglist[] table provided in the unix</div><div>systems, mapping sig=
nal numbers to signal descriptions, e.g. SIGINT -&gt;</div><div>&quot;Inter=
rupted&quot;. On native windows though, this table does not exist, and</div=
><div>emacs simulates it in src/sysdep.c:init_signals() so as to conform wi=
th</div><div>the rest of the code which expects this table to be there.</di=
v><div><br></div><div>init_signals() only populates the descriptions in the=
 C table when emacs is not</div><div>!initialized, i.e. during the dumping =
phase. When emacs is thus ran</div><div>normally, it expects this table to =
have been loaded from the dump into</div><div>memory.</div><div><br></div><=
div>This table though does not appear to make it through to the dump in</di=
v><div>emacs-27.=C2=A0 Having a look at the new pdumper, it looks like that=
 it</div><div>performs differently than its predecessor. It seems as if it<=
/div><div>only cover lisp constructs, while Unexec was also dumping the dat=
a</div><div>section of the process from memory? If true then, it implies th=
at this</div><div>table is not eligible for dumping any more (since it is a=
 C array), but should always be</div><div>initialised when emacs is invoked=
 by the user.=C2=A0 This has a very</div><div>simple solution, taking out t=
he if (!initialized) line in</div><div>src/sysdep.c:init_signals():</div><d=
iv><br></div><div><div>diff --git a/src/sysdep.c b/src/sysdep.c</div><div>i=
ndex f94ce4d492..5b4ec68e6b 100644</div><div>--- a/src/sysdep.c</div><div>+=
++ b/src/sysdep.c</div><div>@@ -1980,7 +1980,6 @@ init_signals (void)</div>=
<div>=C2=A0#endif</div><div>=C2=A0</div><div>=C2=A0#if !HAVE_DECL_SYS_SIGLI=
ST &amp;&amp; !defined _sys_siglist</div><div>-=C2=A0 if (! initialized)</d=
iv><div>=C2=A0 =C2=A0 =C2=A0{</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0sys_sigl=
ist[SIGABRT] =3D &quot;Aborted&quot;;</div><div>=C2=A0# ifdef SIGAIO</div><=
/div><div><br></div><div>The ert test attached to this bug report then pass=
es.</div><div><br></div><div>The above is not an issue in emacs-28 because =
the conversion from</div><div>signal number to description is delegated to =
Gnulib with Paul Eggert&#39;s</div><div>df589d36817a8804d67f133890b2f453aef=
df3c1 &quot;Simplify by using Gnulib</div><div>sigdescr_np module&quot; com=
mit.</div></div></div></div></div>

--0000000000004e8fef05ba7dc39c--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46284; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 4 Feb 2021 03:26:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 03 22:26:07 2021
Received: from localhost ([127.0.0.1]:39355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l7VHT-0007dL-2E
	for submit <at> debbugs.gnu.org; Wed, 03 Feb 2021 22:26:07 -0500
Received: from lists.gnu.org ([209.51.188.17]:40278)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1l7QzR-0006tR-Dm
 for submit <at> debbugs.gnu.org; Wed, 03 Feb 2021 17:51:14 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:36020)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1l7QzR-0001Kr-4v
 for bug-gnu-emacs@HIDDEN; Wed, 03 Feb 2021 17:51:13 -0500
Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]:46395)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1l7QzM-0006WL-54
 for bug-gnu-emacs@HIDDEN; Wed, 03 Feb 2021 17:51:12 -0500
Received: by mail-oi1-x236.google.com with SMTP id k25so1631313oik.13
 for <bug-gnu-emacs@HIDDEN>; Wed, 03 Feb 2021 14:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=IT64Zre32yk8WoRseunfRiDQNNm+6T0tJ8aH7d8Veg8=;
 b=bJmb/EsJcI7BADY8RYhmBsYPgtr/eSzzR+30759+Q2b1Z2Zdlb610Bz7Sc8bOrobUm
 +KckNFg7iNGca9rH4O8X5fbd/YuhNfruq9aQpC19XhwiwKvO4WCVYPnmf520giCICUij
 hVVjU7tiAjRBzuNE9LNNNxinTxGACRa6YciqkQHPAbPd6+QTrRLcM4GHRyUy3g0QSvGy
 G6LM+HFZ4EwWTQOixq4tHVGoyHLrccEYP9tuBDGCkSLZleAuTZ5WxhUCASSLhPNgJt/l
 iXLMjn2jbpYpzH37xR+EhT3mvLqSA5/yYZAPjJdB8WW9gyTn0FcsmBJhzVhyhGKMLaZa
 3cdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=IT64Zre32yk8WoRseunfRiDQNNm+6T0tJ8aH7d8Veg8=;
 b=tR/c7hZeSSJOc4dczgWtLcYQmq4x29DNW6/s4e1x8+4llOjDSUvaAj8j1nRqBmLUVE
 wlpaYL2KIxnEq+1mqr3PL+HrHCj9eWPumBebGZIUgN1ttSBOKWE3HvY9rocPicNIIiQw
 in3W7W5riM0FD3a4iQgGsvd4UcWW0Q5p1jcaVN7X0jV5DW0ilL6dbBmPP7aonujws9yQ
 U1iGcTYwk4hp9xEwCI8+RJNM+8knh/o2oyCm8ec2sxOHOG7Ql3fEIUodVfclcP9fCJ/H
 zl2h24ZwQQv0skBYAQCwMBI5oHF7TxjSgnoSCEsUn0qNnEoLpscmGaGXsnCgDwzCwnxK
 bL9Q==
X-Gm-Message-State: AOAM530hA0REK26H1722xWe0JVdLx3OiRkDwrRhk6soZOpIGaqzk3EDs
 oAh3bfAtaDqLlrchvE+Z7KREQ8fS7ov1A+zjEF224Scc/14qMw==
X-Google-Smtp-Source: ABdhPJxC2FgkgLPtw2W4d2zb11x/ghTe2KXeqdBgvYArLsaCtg+myFThOnRnndN2rDCjlxEH2+k5lp5q0shoYIdbLc8=
X-Received: by 2002:aca:7206:: with SMTP id p6mr3596275oic.78.1612392665615;
 Wed, 03 Feb 2021 14:51:05 -0800 (PST)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Wed, 3 Feb 2021 22:50:54 +0000
Message-ID: <CAMRHuGB9j3ZT9oW=0T17+RyVBHa5F8LqWSOYkx=kV5LibF+iAg@HIDDEN>
Subject: 27.1; emacs-27: windows-nt regression with process sentinel's change
 description argument
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/mixed; boundary="00000000000012a67105ba766c2d"
Received-SPF: pass client-ip=2607:f8b0:4864:20::236;
 envelope-from=ioannis.kappas@HIDDEN; helo=mail-oi1-x236.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 03 Feb 2021 22:26:05 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--00000000000012a67105ba766c2d
Content-Type: multipart/alternative; boundary="00000000000012a66f05ba766c2b"

--00000000000012a66f05ba766c2b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There appears to be a bug in emacs-27 on windows-nt when a call is
made to a process' sentinel in response to a kill- or
interrupt-process call.

The second argument to the sentinel (the "string describing the
change") is set to a "unknown signal" rather than to "interrupt\n" as
it was the case in the latest emacs-26 or in emacs-28 branches:

| system-version | second argument passed to the sentinel |
|----------------+----------------------------------------|
|        26.3.50 | interrupted\n                          |
|        27.1.91 | unknown signal\n                       |
|        28.0.50 | interrupted\n                          |

The expectation is that, under windows-nt, the process sentinel should
pass in an "interrupted\n" value to the change description
argument when interrupt-process has successfully interrupted a process.

An ert test is included to showcase the issue that only fails in
emacs-27 on windows-nt. The test starts an idle emacs process,
sets-process-sentinel,
calls interrupt-process on it, and then compares the sentinel's second
argument whether it is the de facto expected "interrupted\n" text or
otherwise. The test fails on the latest emasc-27 since the argument that
emacs is passing in is "unknown signal".

To execute, save the test file and execute the following command:

emacs.exe -batch -l ert -l set-process-sentinel-test.el -f
ert-run-tests-batch-and-exit

The test will fail on emacs-27 but passes as expected in emacs-26 or the
master branch.

Initial analysis indicated this could be an emacs-27 regression caused by
the move to pdumper,
affecting any functionality that converts signal numbers to text
description. Analysis to follow.

---
set-process-sentinel is a built-in function in =E2=80=98src/process.c=E2=80=
=99.

(set-process-sentinel PROCESS SENTINEL)

Give PROCESS the sentinel SENTINEL; nil for default.
The sentinel is called as a function when the process changes state.
It gets two arguments: the process, and a string describing the change.


In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-11-19 built on fv-az68-340
Repository revision: ec297125a76481c55390d0b329e541907879d6f3
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0

Configured using:
 'configure --prefix=3D/mingw64 --build=3Dx86_64-w64-mingw32 --with-modules
 --without-dbus --without-compress-install 'CFLAGS=3D-march=3Dx86-64
 -mtune=3Dgeneric -O2 -pipe' CPPFLAGS=3D-D__USE_MINGW_ANSI_STDIO=3D1
 'LDFLAGS=3D-pipe
 -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER GMP

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

--00000000000012a66f05ba766c2b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><font face=3D"monospace">T=
here appears to be a bug in emacs-27 on windows-nt when a call is</font></d=
iv><div><font face=3D"monospace">made to a process&#39; sentinel in respons=
e to a kill- or</font></div><div><font face=3D"monospace">interrupt-process=
 call.</font></div><div><font face=3D"monospace"><br></font></div><div><fon=
t face=3D"monospace">The second argument to the sentinel (the &quot;string =
describing the</font></div><div><font face=3D"monospace">change&quot;) is s=
et to a &quot;unknown signal&quot; rather than to &quot;interrupt\n&quot; a=
s</font></div><div><font face=3D"monospace">it was the case in the latest e=
macs-26 or in emacs-28 branches:</font></div><div><font face=3D"monospace">=
<br></font></div><div><font face=3D"monospace">| system-version | second ar=
gument passed to the sentinel |</font></div><div><font face=3D"monospace">|=
----------------+----------------------------------------|</font></div><div=
><font face=3D"monospace">|=C2=A0 =C2=A0 =C2=A0 =C2=A0 26.3.50 | interrupte=
d\n=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |</font></div><div><font face=3D"monospace">|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 27.1.91 | unknown signal\n=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|</font></div><div><=
font face=3D"monospace">|=C2=A0 =C2=A0 =C2=A0 =C2=A0 28.0.50 | interrupted\=
n=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 |</font></div><div><font face=3D"monospace"><br></font></=
div><div><div><font face=3D"monospace">The expectation=C2=A0is that, under =
windows-nt, the process sentinel should</font></div><div><font face=3D"mono=
space">pass in an &quot;interrupted\n&quot; value to the change description=
</font></div><div><font face=3D"monospace">argument when interrupt-process =
has successfully=C2=A0interrupted a process.</font></div></div><div><font f=
ace=3D"monospace"><br></font></div><div><span style=3D"font-family:monospac=
e">An ert test is included to showcase the issue that only fails in</span><=
br></div><div><font face=3D"monospace">emacs-27 on windows-nt. The test sta=
rts an idle emacs process, sets-process-sentinel,</font></div><div><font fa=
ce=3D"monospace">calls=C2=A0</font><span style=3D"font-family:monospace">in=
terrupt-process on it, and then compares the sentinel&#39;s second</span></=
div><div><font face=3D"monospace">argument whether it is the de facto expec=
ted &quot;interrupted\n&quot; text or</font></div><div><font face=3D"monosp=
ace">otherwise. The test fails on the latest emasc-27 since the argument th=
at</font></div><div><font face=3D"monospace">emacs is passing in is &quot;u=
nknown signal&quot;.</font></div><div><font face=3D"monospace"><br></font><=
/div><div><font face=3D"monospace">To execute, save the test file and execu=
te the following command:</font></div><div><font face=3D"monospace"><br></f=
ont></div><div><font face=3D"monospace">emacs.exe -batch -l ert -l set-proc=
ess-sentinel-test.el -f ert-run-tests-batch-and-exit<br></font></div><div><=
font face=3D"monospace"><br></font></div><div><font face=3D"monospace">The =
test will fail on emacs-27 but passes as expected in emacs-26 or the master=
 branch.</font></div><div><font face=3D"monospace"><br></font></div><div><f=
ont face=3D"monospace">Initial analysis indicated this could be an emacs-27=
 regression caused by the move to pdumper,=C2=A0</font></div><div><font fac=
e=3D"monospace">affecting any functionality that converts signal numbers to=
 text description. Analysis to follow.</font></div><div><font face=3D"monos=
pace"><br></font></div><div><font face=3D"monospace">---</font></div><div><=
font face=3D"monospace"><div>set-process-sentinel is a built-in function in=
 =E2=80=98src/process.c=E2=80=99.</div><div><br></div><div>(set-process-sen=
tinel PROCESS SENTINEL)</div><div><br></div><div>Give PROCESS the sentinel =
SENTINEL; nil for default.</div><div>The sentinel is called as a function w=
hen the process changes state.</div><div>It gets two arguments: the process=
, and a string describing the change.</div><div><br></div></font></div><div=
><font face=3D"monospace"><br></font></div><div><font face=3D"monospace"><d=
iv>In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)</div><div>=C2=A0of 2020-=
11-19 built on fv-az68-340</div><div>Repository revision: ec297125a76481c55=
390d0b329e541907879d6f3</div><div>Repository branch: master</div><div>Windo=
wing system distributor &#39;Microsoft Corp.&#39;, version 10.0</div><div><=
div><br></div><div>Configured using:</div><div>=C2=A0&#39;configure --prefi=
x=3D/mingw64 --build=3Dx86_64-w64-mingw32 --with-modules</div><div>=C2=A0--=
without-dbus --without-compress-install &#39;CFLAGS=3D-march=3Dx86-64</div>=
<div>=C2=A0-mtune=3Dgeneric -O2 -pipe&#39; CPPFLAGS=3D-D__USE_MINGW_ANSI_ST=
DIO=3D1</div><div>=C2=A0&#39;LDFLAGS=3D-pipe</div><div>=C2=A0-Wl,--dynamicb=
ase,--high-entropy-va,--nxcompat,--default-image-base-high&#39;&#39;</div><=
div><br></div><div>Configured features:</div><div>XPM JPEG TIFF GIF PNG RSV=
G SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2</div><div>HARFBUZZ ZLIB TOOLKIT=
_SCROLL_BARS MODULES THREADS JSON PDUMPER GMP</div><div><br></div><div>Impo=
rtant settings:</div><div>=C2=A0 value of $LANG: ENG</div><div>=C2=A0 local=
e-coding-system: cp1252</div></div><div><br></div></font></div></div></div>=
</div></div></div></div></div>

--00000000000012a66f05ba766c2b--

--00000000000012a67105ba766c2d
Content-Type: application/octet-stream; name="set-process-sentinel-test.el"
Content-Disposition: attachment; filename="set-process-sentinel-test.el"
Content-Transfer-Encoding: base64
Content-ID: <f_kkq056t80>
X-Attachment-Id: f_kkq056t80

Ozs7IC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQ0KKHJlcXVpcmUgJ2VydCkNCg0KKGVydC1k
ZWZ0ZXN0IHByb2Nlc3Mtc2VudGluZWwtaW50ZXJydXB0LWV2ZW50ICgpDQogICJUZXN0IHRoYXQg
aW50ZXJydXB0aW5nIGEgcHJvY2VzcyB1bmRlciB3aW5kb3dzIHNlbmRzIHRoZQ0KICBcImludGVy
cnVwdFwiIGV2ZW50IHRvIHRoZSBwcm9jZXNzIHNlbnRpbmVsLiAiDQogIDpleHBlY3RlZC1yZXN1
bHQgKGlmIChlcSAnd2luZG93cy1udCBzeXN0ZW0tdHlwZSkNCgkJICAgICAgIDpwYXNzZWQNCgkJ
ICAgICA6ZmFpbGVkKQ0KDQogIChtZXNzYWdlICI6c3lzdGVtICVzIDp2ZXJzaW9uICVzIiBzeXN0
ZW0tY29uZmlndXJhdGlvbiBlbWFjcy12ZXJzaW9uKQ0KDQogICh3aXRoLXRlbXAtYnVmZmVyIA0K
ICAgIChsZXQqICgocHJvYy1idWYgKGN1cnJlbnQtYnVmZmVyKSkNCg0KCSAgIDs7IHN0YXJ0IGEg
bmV3IGVtYWNzIHByb2Nlc3MgdG8gd2FpdCBpZGxlc2x5IHRvIGJlDQoJICAgOzsgaW50ZXJydXB0
ZWQNCgkgICAoY21kICJlbWFjcyAtUSAtLWJhdGNoIC0tZXZhbD1cIihzaXQtZm9yIDUwMDAwKVwi
IikNCgkgICAocHJvYyAoc3RhcnQtZmlsZS1wcm9jZXNzLXNoZWxsLWNvbW1hbmQNCiAgICAgICAg
ICAgICAgICAgICJ0ZXN0L3Byb2Nlc3Mtc2VudGluZWwtc2lnbmFsLWV2ZW50IiBwcm9jLWJ1ZiBj
bWQpKQ0KDQoJICAgKGV2ZW50cyAnKCkpKQ0KICAgICAgDQogICAgICA7OyBjYXB0dXJlIGFueSBp
bmNvbWluZyBldmVudHMNCiAgICAgIChzZXQtcHJvY2Vzcy1zZW50aW5lbCBwcm9jIChsYW1iZGEg
KHByb2MgZXZlbnQpDQoJCQkJICAgKHB1c2ggZXZlbnQgZXZlbnRzKQ0KCQkJCSAgICkpDQogICAg
ICANCiAgICAgIDs7IHdhaXQgZm9yIHRoZSBwcm9jZXNzIHRvIHN0YXJ0DQogICAgICAoc2xlZXAt
Zm9yIDIpDQogICAgICAoc2hvdWxkIChlcXVhbCAncnVuIChwcm9jZXNzLXN0YXR1cyBwcm9jKSkp
DQoNCiAgICAgIDs7IGludGVycnVwdCBwcm9jZXNzIGFuZCB3YWl0IHRvIGRpZQ0KICAgICAgKGlu
dGVycnVwdC1wcm9jZXNzIHByb2MpDQogICAgICAoc2xlZXAtZm9yIDIpDQoNCiAgICAgIDs7IHNo
b3VsZCBoYXZlIHJlY2VpdmVkIFNJR0lOVA0KICAgICAgKHNob3VsZCAoZXF1YWwgJ3NpZ25hbCAo
cHJvY2Vzcy1zdGF0dXMgcHJvYykpKQ0KICAgICAgKHNob3VsZCAoZXF1YWwgMiAocHJvY2Vzcy1l
eGl0LXN0YXR1cyBwcm9jKSkpICAgICAgDQoNCiAgICAgIDs7IGFuZCB0aGUgY2hhbmdlIGRlc2Ny
aXB0aW9uIHNob3VsZCBiZSAiaW50ZXJydXB0Ig0KICAgICAgKHNob3VsZCAoZXF1YWwgJygiaW50
ZXJydXB0XG4iKSBldmVudHMpKQ0KDQogICAgICAobWVzc2FnZSAiZXZlbnRzICVzIiBldmVudHMp
DQogICAgICApKSkNCg0K
--00000000000012a67105ba766c2d--




Acknowledgement sent to Ioannis Kappas <ioannis.kappas@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#46284; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 4 Feb 2021 16:30:02 UTC

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