bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Morten Welinder]

1. Create the following perl script named "ttt":

#!/usr/bin/perl -w
use strict;
my $rc = system($ENV{EDITOR});
my $err = $?;
print STDERR "\nrc=$rc  err=$err\n";

2. Run   EDITOR='/usr/bin/emacs -Q' ./ttt
Emacs comes up normally

3. In shell window, press Ctrl-C
Observe: "rc=0  err=0"
Expected: non-zero values

4. Run   EDITOR='xterm -e /usr/bin/emacs -Q' ./ttt
Emacs comes up normally as does an xterm window

5. In shell window, press Ctrl-C
Observe: "rc=512  err=512"
This is what's expected.


M.






TL;DR for below: openSUSE Leap 15.4 system; no local changes

In GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version
3.24.31, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: openSUSE Leap 15.4

Recent messages:
[irrelevant -- different process]

Configured using:
 'configure --disable-build-details --with-pop --without-hesiod
 --with-gameuser=:games --with-kerberos --with-kerberos5
 --with-file-notification=inotify --with-modules --enable-autodepend
 --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
 --datadir=/usr/share --localstatedir=/var --sharedstatedir=/var/lib
 --libexecdir=/usr/lib
 --enable-locallisppath=/usr/share/emacs/27.2/site-lisp:/usr/share/emacs/site-lisp
 --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
 --with-gif --with-png --with-rsvg --with-dbus --with-xft --without-gpm
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 --x-includes=/usr/include --x-libraries=/usr/lib64 --with-libotf
 --with-m17n-flt --with-cairo --with-xwidgets --build=x86_64-suse-linux
 --with-dumping=pdumper 'CFLAGS=-fmessage-length=0 -grecord-gcc-switches
 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
 -fasynchronous-unwind-tables -fstack-clash-protection -g -D_GNU_SOURCE
 -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS
 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -fno-optimize-sibling-calls -fno-PIE -DSYSTEM_PURESIZE_EXTRA=55000
 -DSITELOAD_PURESIZE_EXTRA=10000 -DPDMP_BASE='\''"emacs-gtk"'\'''
 'LDFLAGS=-Wl,-no-pie -Wl,-O2''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_NUMERIC: POSIX
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Perl

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/site-start.d/lilypond-init hides
/usr/share/emacs/site-lisp/lilypond-init

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib perl-mode paren preview-latex auto-loads tex-site
ispell delsel lpr easy-mmode pcase tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 51780 9816)
 (symbols 48 6350 1)
 (strings 32 17400 2316)
 (string-bytes 1 943121)
 (vectors 16 10821)
 (vector-slots 8 176612 9102)
 (floats 8 24 40)
 (intervals 56 326 0)
 (buffers 1000 13))

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Morten Welinder <mwelinder@gmail.com> writes:

> 1. Create the following perl script named "ttt":

Or an easier way to reproduce the issue:

./src/emacs -Q; echo $?

and then "kill -INT" the process and observe that it echoes "0".

This issue is still present in Emacs 29.

It does seem like a bug -- I'd expect a non-zero exit code in this case.
Eli, what do you think?

(And...  I'm not sure where the action taken for the signal really is
after poking at the

  maybe_fatal_sig (SIGINT);

code paths a few minutes.)

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 58440@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 12 Oct 2022 13:22:28 +0200
> 
> Morten Welinder <mwelinder@gmail.com> writes:
> 
> > 1. Create the following perl script named "ttt":
> 
> Or an easier way to reproduce the issue:
> 
> ./src/emacs -Q; echo $?
> 
> and then "kill -INT" the process and observe that it echoes "0".

What happens if you say

  ./src/emacs -Q && echo 'OK'

does it say OK when you kill Emacs with SIGINT?

> This issue is still present in Emacs 29.
> 
> It does seem like a bug -- I'd expect a non-zero exit code in this case.

I very much doubt that the above is the same problem: Morten didn't
involve Python without a good reason.

And I'm not sure we have anything to do with what Morten reports: how
do we know if Python or its 'system' call blocks some signals, or does
some other non-trivial stuff with them?  Likewise with xterm.

> (And...  I'm not sure where the action taken for the signal really is
> after poking at the
> 
>   maybe_fatal_sig (SIGINT);
> 
> code paths a few minutes.)

In a GUI session, AFAIU SIGINT is handled as a fatal signal, and
should cause Emacs to shut down and return with exit code of 1.  Are
you saying that you don't see that in a debugger?  (I don't have
access to a GNU/Linux system where I can run a GUI Emacs session.)

By contrast, in a TTY (a.k.a. "-nw") session, SIGINT causes a keyboard
quit (we reprogram the keyboard to raise SIGINT when the user preses
C-g), so Emacs should not exit at all if SIGINT is delivered to it.
And Ctrl-C doesn't cause SIGINT anyway.

So I'd appreciate if Morten could explain some more of what he thinks
is going on and why he thinks this is an Emacs problem to begin with.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What happens if you say
>
>   ./src/emacs -Q && echo 'OK'
>
> does it say OK when you kill Emacs with SIGINT?

Yes.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Mattias Engdegård]

> It does seem like a bug -- I'd expect a non-zero exit code in this case. 

It's by design, more or less: see handle_interrupt_signal in keyboard.c. Whether that design is desired or not is a different matter.

(C-g should probably not generate a signal in the first place; it creates more problems than it solves.)

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: mwelinder@gmail.com,  58440@debbugs.gnu.org
> Date: Wed, 12 Oct 2022 16:41:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What happens if you say
> >
> >   ./src/emacs -Q && echo 'OK'
> >
> > does it say OK when you kill Emacs with SIGINT?
> 
> Yes.

That's strange.  So the next step is to attach a debugger to Emacs
before delivering SIGINT to it, and see why we don't exit with the
status of 1.

What I verified is that when I do

  ./src/emacs -Q -nw && echo 'OK'

and then type "kill -INT EMACS-PID" from another terminal, Emacs does
a keyboard quit (i.e. flashes the display and says "Quit" in the
echo-area), which is exactly as I expect.  So in the -nw case, the
installed SIGINT handler is called and does what is expected.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

>> It does seem like a bug -- I'd expect a non-zero exit code in this case. 
>
> It's by design, more or less: see handle_interrupt_signal in
> keyboard.c. Whether that design is desired or not is a different
> matter.
>
> (C-g should probably not generate a signal in the first place; it
> creates more problems than it solves.)

Hm, sounds like it...

But looking at the code:

----
/* The SIGINT handler.

   If we have a frame on the controlling tty, we assume that the
   SIGINT was generated by C-g, so we call handle_interrupt.
   Otherwise, tell maybe_quit to kill Emacs.  */

static void
handle_interrupt_signal (int sig)
----

But if I 

./src/emacs -Q && echo 'OK'

and then `C-g', that has no effect, but we still hit this logic?  And
even if:

(./src/emacs -Q && echo 'OK' )&

where the Emacs definitely isn't attached to the tty, then `C-g' in the
terminal can't have any effect (and doesn't).  But we still end up in
this code?

That seems like a bug, possibly?

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>> It does seem like a bug -- I'd expect a non-zero exit code in this case. 
>>
>> It's by design, more or less: see handle_interrupt_signal in
>> keyboard.c. Whether that design is desired or not is a different
>> matter.
>>
>> (C-g should probably not generate a signal in the first place; it
>> creates more problems than it solves.)
>
> Hm, sounds like it...
>
> But looking at the code:

And anyway -- we do exit like we're supposed to, just not with the
correct value.  So I'm not sure this is an explanation for this
behaviour?

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Mattias Engdegård]

12 okt. 2022 kl. 17.54 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> And anyway -- we do exit like we're supposed to, just not with the
> correct value.  So I'm not sure this is an explanation for this
> behaviour?

What the correct value is a matter of debate. For instance, it could be argued that SIGINT to a GUI-only Emacs is to be interpreted as a 'please terminate normally' message, in which the exit code 0 may be appropriate.

I have no strong opinion on what it should be (and am not defending status quo); it doesn't seem very important but the original reporter may disagree.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> What the correct value is a matter of debate. For instance, it could
> be argued that SIGINT to a GUI-only Emacs is to be interpreted as a
> 'please terminate normally' message, in which the exit code 0 may be
> appropriate.

That's true.  Perhaps it'd be instructive to check what other GUI
programs return on SIGINT?

Let's see...  gimp returned non-zero.  So did xterm.  And so did xeyes.

100% non-zero.  😁

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Mattias Engdegård]

13 okt. 2022 kl. 08.34 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> That's true.  Perhaps it'd be instructive to check what other GUI
> programs return on SIGINT?
> 
> Let's see...  gimp returned non-zero.  So did xterm.  And so did xeyes.

Yes, it's the natural outcome in any normal GUI application that doesn't have Emacs's complicated relation to SIGINT.

I certainly don't mind if you change Emacs in this respect. The root of the problem is that we use SIGINT for C-g. More precisely, that we set C-g as the INTR char for TTY frames. (This is done for historical reasons and should be understood in that context.)

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> Yes, it's the natural outcome in any normal GUI application that
> doesn't have Emacs's complicated relation to SIGINT.
>
> I certainly don't mind if you change Emacs in this respect. 

I think it'd make sense to change the exit code here -- it seems more
logical, and I think the potential for breakage is small.  (I mean,
there may be people that have scripts that rely on Emacs having a zero
exit code on SIGINT, but it seems rather unlikely.)

Anybody have any objections to making this change?

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 58440@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>,  Morten Welinder
>  <mwelinder@gmail.com>
> Date: Thu, 13 Oct 2022 10:12:03 +0200
> 
> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
> 
> > Yes, it's the natural outcome in any normal GUI application that
> > doesn't have Emacs's complicated relation to SIGINT.
> >
> > I certainly don't mind if you change Emacs in this respect. 
> 
> I think it'd make sense to change the exit code here -- it seems more
> logical, and I think the potential for breakage is small.  (I mean,
> there may be people that have scripts that rely on Emacs having a zero
> exit code on SIGINT, but it seems rather unlikely.)
> 
> Anybody have any objections to making this change?

What change did you have in mind?  C-g should still raise SIGINT on
TTY frames, so if that's the change you propose, I'm against it.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think it'd make sense to change the exit code here -- it seems more
>> logical, and I think the potential for breakage is small.  (I mean,
>> there may be people that have scripts that rely on Emacs having a zero
>> exit code on SIGINT, but it seems rather unlikely.)
>> 
>> Anybody have any objections to making this change?
>
> What change did you have in mind?  C-g should still raise SIGINT on
> TTY frames, so if that's the change you propose, I'm against it.

I'm proposing that we exit on a non-zero value if and when we decide to
exit after a SIGKILL.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Mattias Engdegård]

13 okt. 2022 kl. 13.31 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> I'm proposing that we exit on a non-zero value if and when we decide to
> exit after a SIGKILL.

Done! Oh, you meant SIGINT. Never mind then.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Thu, 13 Oct 2022 15:16:25 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  58440@debbugs.gnu.org,
>  mwelinder@gmail.com
> 
> 13 okt. 2022 kl. 13.31 skrev Lars Ingebrigtsen <larsi@gnus.org>:
> 
> > I'm proposing that we exit on a non-zero value if and when we decide to
> > exit after a SIGKILL.
> 
> Done!

That was AFAIU a proposal for discussion, not a request to make the
change right there and then.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: mattias.engdegard@gmail.com,  58440@debbugs.gnu.org,  mwelinder@gmail.com
> Date: Thu, 13 Oct 2022 13:31:36 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think it'd make sense to change the exit code here -- it seems more
> >> logical, and I think the potential for breakage is small.  (I mean,
> >> there may be people that have scripts that rely on Emacs having a zero
> >> exit code on SIGINT, but it seems rather unlikely.)
> >> 
> >> Anybody have any objections to making this change?
> >
> > What change did you have in mind?  C-g should still raise SIGINT on
> > TTY frames, so if that's the change you propose, I'm against it.
> 
> I'm proposing that we exit on a non-zero value if and when we decide to
> exit after a SIGKILL.

SIGINT, you mean, yes?

How do you see that we exit with zero status now?  I mean, not by
looking what the shell says, but by tracing the code which handles
SIGINT?  I'd like to see what code we are talking about before making
up my mind about the change you propose.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I'm proposing that we exit on a non-zero value if and when we decide to
>> > exit after a SIGKILL.
>> 
>> Done!
>
> That was AFAIU a proposal for discussion, not a request to make the
> change right there and then.

I think that was a joke.  😀

Eli Zaretskii <eliz@gnu.org> writes:

> How do you see that we exit with zero status now?  I mean, not by
> looking what the shell says, but by tracing the code which handles
> SIGINT?  I'd like to see what code we are talking about before making
> up my mind about the change you propose.

I haven't been able to follow the interrupt handling logic (after
looking at it for a couple minutes), so I don't know.

bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,
>   58440@debbugs.gnu.org,
>   mwelinder@gmail.com
> Date: Thu, 13 Oct 2022 21:03:19 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > I'm proposing that we exit on a non-zero value if and when we decide to
> >> > exit after a SIGKILL.
> >> 
> >> Done!
> >
> > That was AFAIU a proposal for discussion, not a request to make the
> > change right there and then.
> 
> I think that was a joke.  😀

"A scalded cat..." and all that.

> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do you see that we exit with zero status now?  I mean, not by
> > looking what the shell says, but by tracing the code which handles
> > SIGINT?  I'd like to see what code we are talking about before making
> > up my mind about the change you propose.
> 
> I haven't been able to follow the interrupt handling logic (after
> looking at it for a couple minutes), so I don't know.

I hope someone else will be able to do that, then.  My reading of the
code is that any fatal signal causes us to exit with exit code 1.