[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 06babb24225d41a76e4aee975380294ca1ee1d7c by Gregory P. Smith in 
branch 'master':
bpo-1054041: Add What's New docs. (GH-11999)
https://github.com/python/cpython/commit/06babb24225d41a76e4aee975380294ca1ee1d7c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +12029

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +11989

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:

i'm curious if this _ever_ comes up so i'd like to leave it in at least through 
some betas.  I don't believe it should be possible.  If it is, it'd probably be 
a restricted execution environment that fails all signal() calls.  all perror 
will do is emit an error message to that effect before continuing so we still 
exit with an error code as the final fallback.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[STINNER Victor]

STINNER Victor  added the comment:

> if (PyOS_setsig(SIGINT, SIG_DFL) == SIG_ERR) {
>perror("signal");  /* Impossible in normal environments. */

In my experience, Python is were impossible things happen. Would it be possible 
to write a better error message to explain what happened?

I expect that if PyOS_setsig() fails, the user cannot do much for that. It may 
be a bug in the libc and so cannot be fixed easily. Maybe we should simply 
ignore the error?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:

This is in for 3.8.

On earlier or unpatched Python versions: application owners have a workaround f 
they do not mind skipping a clean application shutdown (destructors) on posix 
platforms:
catch KeyboardInterrupt, reset SIGINT to SIG_DFL, kill(getpid(), SIGINT).  If 
you somehow need the python destructor cleanup (never guaranteed, so unwise to 
_depend_ on it) you could do that in a C atexit handler.

On Windows the workaround is easier without altering clean shutdown, catch 
KeyboardInterrupt and sys.exit(0xC13A - 2**32).

--
assignee:  -> gregory.p.smith
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 38f11cc3f62db11a4a24354bd06273322ac91afa by Gregory P. Smith in 
branch 'master':
bpo-1054041: Exit properly after an uncaught ^C. (#11862)
https://github.com/python/cpython/commit/38f11cc3f62db11a4a24354bd06273322ac91afa


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +11895
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Eryk Sun]

Change by Eryk Sun :


Added file: https://bugs.python.org/file48142/winsig.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Eryk Sun]

Eryk Sun  added the comment:

Gregory's last example reminded me that CMD checks for STATUS_CONTROL_C_EXIT 
for more than simply printing "^C". It also breaks out of a FOR loop when 
interactive and prompts to continue when executing a batch script.

Normally CMD also gets a console control event when the user presses Ctrl+C, so 
it knows about the Ctrl+C regardless of the child's exit status. One exception 
is when we start a process with a new console via CMD's `start` command. In 
this case CMD doesn't get a Ctrl+C event, since it's attached to a different 
console. Another exception is a simulated keyboard interrupt (e.g. from C raise 
SIGINT or Python _thread.interrupt_main). In these cases, CMD depends on the 
exit status value to determine whether the process was terminated by the 
default Ctrl+C handler. I've demonstrated this in the files winsig.bat and 
winsig.py. Put both in the same directory and run winsig.bat.

--
Added file: https://bugs.python.org/file48141/winsig.bat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:

jwilk: Confirmed.  The exit code is not enough, we must trigger the SIG_DFL 
handler.

to reproduce:

 while true; do ./sig.py ; done

with the attached sig.py.

pass a parameter to sig.py to have it exit 130 instead of triggering SIG_DFL...

--
Added file: https://bugs.python.org/file48138/sig.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm assuming the calling shell uses waitpid() and then WIFSIGNALED()?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Jakub Wilk]

Jakub Wilk  added the comment:

This issue was reported because with the current behavior, "the script will not 
properly exit on C-c". Exiting with code 128+SIGINT will not fix this.

Please re-raise the signal.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Eryk Sun]

Eryk Sun  added the comment:

For Windows, the default console control handler calls 
ExitProcess(STATUS_CONTROL_C_EXIT). If CMD is waiting on an application that 
exits with STATUS_CONTROL_C_EXIT, it prints "^C" to indicate the process was 
killed by Ctrl+C. For example:

>>> STATUS_CONTROL_C_EXIT = 0xC13A - 2**32
>>> STATUS_CONTROL_C_EXIT
-1073741510
>>> sys.exit(STATUS_CONTROL_C_EXIT)
^C

C:\>echo %errorlevel%
-1073741510

Note that switching to SIG_DFL with raise(SIGINT) does not invoke the default 
console control handler in Windows. It just invokes the default raise() 
behavior, which is to call _exit(3). This exit status value of 3 is arbitrary 
and meaningless.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I expect that'll work as desired and avoids the re-raising of the signal.

Unless told otherwise I assume this should be a POSIX specific platform 
behavior.  ie: no return value alteration due to an uncaught KeyboardInterrupt 
on the Windows API build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[STINNER Victor]

STINNER Victor  added the comment:

> A question that leads to is what _is_ the correct value.

What do you think of using a short test program (ex: uses raise(SIGINT)) in 
./configure to get the "default exit code" to define a constant, and then use 
the constant for exit() in Python?

I dislike the idea of raising signals in general. The exact behavior of signals 
depends too much on the OS, it's hard to get it right. But having a 
configurable exit code looks safe and simple enough.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Change by Gregory P. Smith :


--
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Taking a renewed look at this 8 years later... I agree, re-triggering the 
signal with the SIG_DFL handler would prevent us from doing the existing 
interpreter shutdown cleanup if we did it too early which would be a behavior 
change other than the exit value correction.

So we should delay the re-signaling kill(getpid(), SIGINT) call until we've 
completed that and are about to exit anyways.

The code has moved around a lot since i generated this patch on a 3.2-ish tree 
so it'll take me a while to untangle what would need to go where to create a PR.

Instead of kill(getpid(), SIGINT) or raise(SIGINT), we could just checking the 
_UnhandledKeyboardInterrupt flag we return our exit valye adjusting it to be 
the one a calling shell may be expecting to indicate a SIGINT.  That goes 
against the advice of https://www.cons.org/cracauer/sigint.html but is likely 
to work.

A question that leads to is what _is_ the correct value.  On Linux the magic 
130 happens to be (SIGINT + 128).  Triggering the libc or kernel supplied 
SIG_DFL handler as a final act avoids us ever needing to know what possible 
mechanisms to indicate this to the parent process are preferred on a platform.  
(if we know it is merely an exit value we could capture that in to a #define 
with a configure.ac check if the + 128 trick were deemed too magical despite 
being what everyone likely implements, standardized or not)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Change by Gregory P. Smith :


--
versions: +Python 3.8 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Samuel Bronson]

Changes by Samuel Bronson naes...@gmail.com:


--
nosy: +SamB

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Jakub Wilk]

Changes by Jakub Wilk jw...@jwilk.net:


--
nosy: +jwilk

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Petri Lehtinen]

Changes by Petri Lehtinen pe...@digip.org:


--
stage: needs patch - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Petri Lehtinen]

Changes by Petri Lehtinen pe...@digip.org:


--
nosy: +petri.lehtinen

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[STINNER Victor]

STINNER Victor victor.stin...@haypocalc.com added the comment:

+kill(getpid(), SIGINT);

kill() doesn't exist on Windows: use raise() which is more portable and doesn't 
require a PID argument.

We may need to do something on Windows for console applications: see 
SetConsoleCtrlHandler(),
http://msdn.microsoft.com/en-us/library/ms686016(v=vs.85).aspx

+self.assertEqual(returncode, -signal.SIGINT,
+ not a SIGINT exit code. process stderr:\n%s % 
stderr)

I don't think that such test can pass on Windows.

--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Reid Kleckner]

Reid Kleckner r...@mit.edu added the comment:

Looks good to me.  Do you need the TODO(gps)'s in there after implementing the 
behavior described?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

- should KeyboardInterrupt always exit with SIGINT, or only if it was actually 
raised by a signal handler?
- if _Py_UnhandledKeyboardInterrupt is defined in Modules/main.c but used in 
Python/pythonrun.c, can't it cause linker errors when embedding Python?
- please use PEP 8 (testKeyboardInterruptSignalExit - test_some_long_name)

--
nosy: +loewis, pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

I wonder whether there is a precedent of some system mapping SIGINT to
an exception. We could probably learn something from them.

 - should KeyboardInterrupt always exit with SIGINT, or only if it was
 actually raised by a signal handler?

IMO, if we give the illusion that the interpreter was actually killed,
we should equate KeyboardInterrupt with SIGINT; any uncaught
KeyboardInterrupt should consequently always lead to raising SIGINT.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith g...@krypto.org added the comment:

 IMO, if we give the illusion that the interpreter was actually killed,
 we should equate KeyboardInterrupt with SIGINT; any uncaught
 KeyboardInterrupt should consequently always lead to raising SIGINT.

Agreed.  Plus that is easier to implement and what I did.

I'll remove the left over TODO(gps) comments (oops) before this is
ever committed. I'm waiting until after 3.2 is released unless the
release manager jumps in and says otherwise.  remaining items:

 1. I need to add a second test case that writes the code to a file
and launches a subprocess executing that file instead of using -c
given that they are different code paths that each need testing.  For
variety I'll probably make that one send an actual SIGINT to the child
process rather than having it raise KeyboardInterrupt.

 2. The tests probably needs a decorator to limit their execution to posix.

 3. Do the signal and kill calls also need to be conditional based on
platform or is the function I put them in already posix-only?  If
necessary I'll protect them with #ifdefs so they don't break a windows
build.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +gregory.p.smith -BreamoreBoy
stage: unit test needed - needs patch
type: behavior - feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +rnk

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Gregory P. Smith]

Gregory P. Smith g...@krypto.org added the comment:

Here's a patch that implements this behavior.  It is too late in the 3.2 
beta/rc cycle to get this into 3.2.  Consider it for 3.3.  I'd like a review.

--
keywords: +needs review, patch
Added file: http://bugs.python.org/file20251/issue1054041-sigint-exit-gps01.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Mark Lawrence]

Mark Lawrence breamore...@yahoo.co.uk added the comment:

I'll close this in a couple of weeks unless someone wants it kept open.

--
nosy: +BreamoreBoy
status: open - pending
type: feature request - behavior
versions: +Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Stefan Krah]

Changes by Stefan Krah stefan-use...@bytereef.org:


--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[Daniel Diniz]

Changes by Daniel Diniz aja...@gmail.com:


--
stage:  - test needed
type:  - feature request
versions: +Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com