Ctrl-C will exit out of Python interpreter in Windows #46018

Dude-X · 2007-12-21T06:16:13Z

BPO	1677
Nosy	@loewis, @mhammond, @jcea, @ronaldoussoren, @amauryfa, @pitrou, @kristjanvalur, @tiran, @tjguk, @ssbr, @bitdancer, @briancurtin
Files	issue1677-python27.patch: Patch of myreadline.c against 2.7 branch issue1677-python3x.patch: Patch of myreadline.c against default branch issue1677-python32.patch: Patch of myreadline.c against 3.2 branch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tjguk'
closed_at = <Date 2012-06-29.21:34:34.009>
created_at = <Date 2007-12-21.06:16:12.899>
labels = ['OS-mac', 'interpreter-core', 'type-bug', 'OS-windows']
title = 'Ctrl-C will exit out of Python interpreter in Windows'
updated_at = <Date 2012-07-03.11:21:22.904>
user = 'https://bugs.python.org/Dude-X'

bugs.python.org fields:

activity = <Date 2012-07-03.11:21:22.904>
actor = 'jcea'
assignee = 'tim.golden'
closed = True
closed_date = <Date 2012-06-29.21:34:34.009>
closer = 'tim.golden'
components = ['Interpreter Core', 'macOS', 'Windows']
creation = <Date 2007-12-21.06:16:12.899>
creator = 'Dude-X'
dependencies = []
files = ['26196', '26202', '26208']
hgrepos = []
issue_num = 1677
keywords = ['patch']
message_count = 34.0
messages = ['58933', '58939', '58940', '58975', '89651', '89655', '104643', '115133', '115139', '115155', '131632', '164064', '164065', '164133', '164150', '164152', '164154', '164187', '164233', '164243', '164244', '164246', '164250', '164252', '164261', '164264', '164275', '164279', '164331', '164335', '164336', '164353', '164592', '164593']
nosy_count = 15.0
nosy_names = ['loewis', 'mhammond', 'jcea', 'ronaldoussoren', 'amaury.forgeotdarc', 'pitrou', 'kristjan.jonsson', 'christian.heimes', 'tim.golden', 'Dude-X', 'Devin Jeanpierre', 'r.david.murray', 'brian.curtin', 'santoso.wijaya', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1677'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

Dude-X · 2007-12-21T06:16:12Z

When running Python 2.5.1 stable in Windows, you can press Ctrl-C as
many times as you want and it will always output Keyboard Interrupt in
the interpreter.
Python 3.0a+ will quit if you press ctrl-c too many times. The last
release of 3.0a2 can handle many interrupts before quitting, but the
latest snapshot (Dec 20th) can not.

Steps to reproduce:
Run python.exe
hold down ctrl-c, or press it many times. It will quit the interpreter
eventually.

tiran · 2007-12-21T09:44:11Z

I don't think it's a critical bug but it may be worth to debug it.

amauryfa · 2007-12-21T09:57:41Z

I get the same behaviour with python 2.5.1, and even 2.4.4 (on Windows
2000): I hold down Ctrl-C, and after ~30 "KeyboardInterrupt", the
interpreter stops.

So this is not 3.0 specific. What is new in python3.0 is that file
objects are implemented in python, and are much slower.
It is possible that when the key buffer is full, the next Ctrl-C kills
the program. And this is more likely to happen with python3.0.

Dude-X · 2007-12-23T21:03:09Z

I wanted to add that this issue also affects python 2.5.1 on the Mac.
Sometimes I may be writing something in the interpreter and I decide to
invalidate my input by pressing Ctrl-C. This will exit the interpreter
occasionally. I think it would be a good idea to see if there's a way
to make the interpreter bullet proof from Ctrl-C, or at least good
enough so that a single Ctrl-c won't cause the interpreter to exit.

amauryfa · 2009-06-23T23:33:14Z

Removing the Windows part: on my machine, repeated Ctrl-C's don't exit the
3.1 interpreter, probably because the io module is now written in C.

ronaldoussoren · 2009-06-24T05:41:10Z

I cannot reproduce this on my machine (running OSX) using 2.5, 2.6 and 3.1
(latest rc).

ronaldoussoren · 2010-04-30T15:03:40Z

Unassigning this issue from myself as I cannot reproduce the issue on OSX.

bitdancer · 2010-08-27T21:39:56Z

I can't reproduce this on windows (in a KVM) with 2.6 or 2.7.

Dude-X · 2010-08-27T22:58:30Z

I tested this on a real Windows 7 machine (64 bit, Ultimate)
I open the command prompt, and I have the latest Pythons installed,
Python 2.6.6, Python 2.7 final, and Python 3.1.2
If I hold down Ctrl-C, it will eventually exit the interpreter.
Though it's not normal to hold down Ctrl-C, in practice that means pressing Ctrl-C
to cancel a currently running script may just exit the interpreter.
Python 3.1 seems really terrible in this regard where sometimes a single Ctrl-C will exit the interpreter.

I have seen this issue fixed in Python 2.5.2 on Windows. It would never exit the interpreter no matter how long I pressed Ctrl-C. I don't see this issue in Linux. I don't have a Mac to test, but I'd like Mac users to test the signal handling in their terminals.

briancurtin · 2010-08-28T14:38:50Z

I'm not able to reproduce this. Do you have anything installed like pyreadline?

ssbr · 2011-03-21T11:07:32Z

Windows 7 64-bit (on the metal, not in a VM), can confirm. Holding down Ctrl+C will (eventually) halt Python on all the versions I have installed: 2.3, 2.7, 3.0, 3.1, 3.2. (All of these are 32-bit Pythons). Haven't done anything silly like try to install readline on Windows.

I also tried it on cygwin Python (2.6), held down for maybe 20 seconds, didn't crash.

ssbr · 2012-06-26T11:17:37Z

For extra clarification, this issue can crop up with even a single press of ctrl-c. It's not really related to multiple presses, except that pressing it more increases the odds of it happening.

tiran · 2012-06-26T11:26:16Z

Could add a printf() to PC/launcher.c:ctrl_c_handler() to test if the handler is called in the error case?

tjguk · 2012-06-27T09:33:46Z

Just to confirm: I can reproduce this more or less consistently on all versions of Python 2.2 -> 3.2 on Windows 7. Those are distribution builds -- ie not debug builds I've made myself. But it certainly does occur on a debug build of 2.7.

I'm trying to narrow it down through some instrumentation (read: printf) on the 2.7 branch. The MSDN page for signal warns that a separate thread will be created for the signal handler which will muddy the waters.

tjguk · 2012-06-27T13:04:05Z

OK, I've run out of time to look, but the culprit looks like it's an odd interaction between my_fgets in myreadline.c and the interrupt handler in signal. There's a section of code which is conditional on ERROR_OPERATION_ABORTED being returned from fgets in the CRT.

That then tries to play ball with a the interrupt handler having fired already (in a separate thread) by sleeping for one second and checking that the handler was tripped. If it has then the function returns one and stuff happens elsewhere; it it hasn't then the function behaves as if EOF (ie Ctrl-Z) was pressed and Python exits.

That's as far as I've got; it looks like a race condition of some sort but I can't see where. I'm not 100% sure that the SIGINT handler is tripping.

amauryfa · 2012-06-27T13:30:34Z

Great analysis!

... by sleeping for one second ...
Note that Sleep(1) only sleeps for 1 millisecond.
Does the issue go away if you replace with Sleep(10)?

tjguk · 2012-06-27T13:31:39Z

That'll be my next move when I get some more time.
I've got someone coming over to see me (about real work!)

tjguk · 2012-06-27T18:47:46Z

OK, it is a race condition between the code in myreadline.c and the
signal_handler in signalmodule.c. It can take between 0 and 3 sleeps for
the myreadline code to see the signal tripped. Patch on its way for 2.7;
VS 2010 downloading so that 3.x patch can be tested.

tjguk · 2012-06-28T09:31:58Z

Attached is a patch against Python 2.7. It checks in a loop for SIGINT and, if it still hasn't fired, assumed Ctrl-Z was pressed which generates the same error.

kristjanvalur · 2012-06-28T11:10:37Z

Shouldn't we be using a proper synchronization primitive? What about waiting for an event?

kristjanvalur · 2012-06-28T11:15:04Z

In fact, there is _PyOS_SigintEvent at the end of signalmodule.c

amauryfa · 2012-06-28T11:33:04Z

Is the ERROR_OPERATION_ABORTED set when Ctrl-Z is hit?

tjguk · 2012-06-28T12:31:51Z

Yep.

tjguk · 2012-06-28T12:35:02Z

To be clear: ERROR_OPERATION_ABORTED is set when Ctrl-Z is hit as the
only thing on a line. If it's just an extra character then it operates
like any other keypress.

tjguk · 2012-06-28T14:49:34Z

This patch is for 2.7 and does enough to solve the issue without a major
rework. The signal module onthe default branch has had a lot of love
recently and I'll definitely make use of that for a 3.x patch.

kristjanvalur · 2012-06-28T15:34:56Z

Hm, I wonder if the test for the SIGINT event is required at all.
Could it be sufficient to simply check for the EOF state? EOF would indicate ctrl z and distinguish it thus from ctrl-c.

tjguk · 2012-06-28T16:46:20Z

Nope. Ctrl-C also sets EOF

tjguk · 2012-06-28T17:10:51Z

And here's a patch for the default branch, using the new sigint event as Kristan suggested.

tjguk · 2012-06-29T14:55:47Z

And here's the patch against 3.2 (essentially the 2.7 patch but allowing for the removal of RISCOS support)

pitrou · 2012-06-29T17:20:56Z

Tim, you've got tabs in your 3.3 patch.
Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the other versions?

tjguk · 2012-06-29T17:23:16Z

Tim, you've got tabs in your 3.3 patch.

Thanks, Antoine. I'll sort that out. (Goodness know how;
none of my editors use tabs).

Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the other versions?

Ummm. Because they were written separately and I didn't
check carefully enough? I'll drop back to 10ms all round;
it never took more than 3 1-ms loops to fire in testing.

python-dev · 2012-06-29T21:14:48Z

New changeset bb4b184e5b33 by Tim Golden in branch '2.7':
Issue bpo-1677: Handle better a race condition between the interactive interpreter and
http://hg.python.org/cpython/rev/bb4b184e5b33

New changeset 52af10209976 by Tim Golden in branch '3.2':
Issue bpo-1677: Handle better a race condition between the interactive interpreter and
http://hg.python.org/cpython/rev/52af10209976

New changeset 9523c122d6fc by Tim Golden in branch 'default':
Issue bpo-1677: Handle better a race condition between the interactive interpreter and
http://hg.python.org/cpython/rev/9523c122d6fc

python-dev · 2012-07-03T11:08:48Z

New changeset 2de5c9ced464 by Jesus Cea in branch '2.7':
Issue bpo-1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/2de5c9ced464

python-dev · 2012-07-03T11:18:47Z

New changeset 4de541fbdd58 by Jesus Cea in branch '3.2':
Issue bpo-1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/4de541fbdd58

New changeset 7937aa6b7e92 by Jesus Cea in branch 'default':
NULL MERGE: Issue bpo-1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/7937aa6b7e92

Dude-X mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Dec 21, 2007

JosephArmbruster mannequin added the OS-windows label Jan 3, 2008

amauryfa added OS-mac and removed interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows labels Jun 23, 2009

amauryfa assigned ronaldoussoren Jun 23, 2009

ronaldoussoren removed their assignment Apr 30, 2010

Dude-X mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows labels Aug 27, 2010

Dude-X mannequin assigned ronaldoussoren Aug 27, 2010

briancurtin unassigned ronaldoussoren Aug 28, 2010

tjguk self-assigned this Jun 28, 2012

tjguk closed this as completed Jun 29, 2012

ezio-melotti transferred this issue from another repository Apr 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ctrl-C will exit out of Python interpreter in Windows #46018

Ctrl-C will exit out of Python interpreter in Windows #46018

Dude-X mannequin commented Dec 21, 2007

Dude-X mannequin commented Dec 21, 2007

tiran commented Dec 21, 2007

amauryfa commented Dec 21, 2007

Dude-X mannequin commented Dec 23, 2007

amauryfa commented Jun 23, 2009

ronaldoussoren commented Jun 24, 2009

ronaldoussoren commented Apr 30, 2010

bitdancer commented Aug 27, 2010

Dude-X mannequin commented Aug 27, 2010

briancurtin commented Aug 28, 2010

ssbr mannequin commented Mar 21, 2011

ssbr mannequin commented Jun 26, 2012

tiran commented Jun 26, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 27, 2012

amauryfa commented Jun 27, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

amauryfa commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 29, 2012

pitrou commented Jun 29, 2012

tjguk commented Jun 29, 2012

python-dev mannequin commented Jun 29, 2012

python-dev mannequin commented Jul 3, 2012

python-dev mannequin commented Jul 3, 2012

Ctrl-C will exit out of Python interpreter in Windows #46018

Ctrl-C will exit out of Python interpreter in Windows #46018

Comments

Dude-X mannequin commented Dec 21, 2007

Dude-X mannequin commented Dec 21, 2007

tiran commented Dec 21, 2007

amauryfa commented Dec 21, 2007

Dude-X mannequin commented Dec 23, 2007

amauryfa commented Jun 23, 2009

ronaldoussoren commented Jun 24, 2009

ronaldoussoren commented Apr 30, 2010

bitdancer commented Aug 27, 2010

Dude-X mannequin commented Aug 27, 2010

briancurtin commented Aug 28, 2010

ssbr mannequin commented Mar 21, 2011

ssbr mannequin commented Jun 26, 2012

tiran commented Jun 26, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 27, 2012

amauryfa commented Jun 27, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 27, 2012

tjguk commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

amauryfa commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

kristjanvalur mannequin commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 28, 2012

tjguk commented Jun 29, 2012

pitrou commented Jun 29, 2012

tjguk commented Jun 29, 2012

python-dev mannequin commented Jun 29, 2012

python-dev mannequin commented Jul 3, 2012

python-dev mannequin commented Jul 3, 2012