Default SIGINT handling dangerous?
Hi all. Is there any way to disable the default asynchronous exception raising SIGINT signal handling? Or a plan to add support for this? My searches on the net found several bug reports and discussions regarding this, but nothing seems final... :-( I believe the current Python default SIGINT handling by raising an asynchronous KeyboardInterrupt exception is dangerous, and can directly cause Python interpreter crashes even if no user code is involved, or any sort of other 'undefined behaviour' if it is. On Windows at least (using Python 3.3.3 at the moment, but seen with earlier versions as well), I occasionally get 'python.exe has stopped working' dialogs when Ctrl-C is pressed (most often if pressed during Python's initialization - loading site.py or earlier). The problem with asynchronous exceptions is, of course, that they can occur at _any_ time, even at the start of a finally: block, effectively causing cleanup code to be skipped even though the programmer intended it to be called even in case of exceptions. My scripts replace the default SIGINT/SIGBREAK signal handlers as soon as possible, and everything works great after that, but things get ugly if Ctrl-C is pressed before the script gets a chance to do this. I could even live with an 'exit with an ugly traceback', but having the process hang or fail so that Windows reports it as non-responding or reports it as 'stopped working' and offers to send failure information to Microsoft? That just leaves a bad taste in my mouth. :-( Also, Python documentation should not helpfully state or infer in several places that user can handle KeyboardInterrupt exceptions to implement Ctrl-C handling. Even if you do manage to catch it, you must never ever ignore it and must terminate your application since it might have already been left in an inconsistent state internally (e.g. some important finally clause got skipped, even one located deep in the Python standard library internals). Doing anything else can only be considered a partially working hack. Another problem is that that multiple SIGINT signals might occur in a sequence and any such KeyboardInterrupt handling can itself be interrupted in the same way as the original code. You can say that this is 'unlikely', or even add additional code to make this even more unlikely, but it still smells bad. :-( Hope this helps. Best regards, Jurko Gospodnetić Below, I've included a few script outputs (tracebacks included) from instances where Python interpreter crashed due to pressing Ctrl-C soon after an empty Python script has been run. In the first of these instances I got the Microsoft's error reporting dialog. In all the later instances I checked the Python process's debug output and every time it included the message: 'Microsoft Visual Studio C Runtime Library has detected a fatal error in python.exe.'. Using: - OS: Windows 7 SP1 x64 - Python 3.3.3 (64-it) - default site.py -------------- Occurrence #1: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "<frozen importlib._bootstrap>", line 755, in _open_registry FileNotFoundError: [WinError 2] The system cannot find the file specified
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function level=0) File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1523, in_find_and_load_unlocked File "<frozen importlib._bootstrap>", line 1477, in _find_module File "<frozen importlib._bootstrap>", line 777, in find_module File "<frozen importlib._bootstrap>", line 768, in _search_registry File "<frozen importlib._bootstrap>", line 755, in _open_registry KeyboardInterrupt
-------------- Occurrence #2: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\codecs.py", line 165, in __init__ def __init__(self, errors='strict'): KeyboardInterrupt
-------------- Occurrence #3: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1523, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 1477, in _find_module File "<frozen importlib._bootstrap>", line 1309, in find_module File "<frozen importlib._bootstrap>", line 1288, in _get_loader File "<frozen importlib._bootstrap>", line 1387, in find_loader File "<frozen importlib._bootstrap>", line 110, in _path_isfile File "<frozen importlib._bootstrap>", line 101, in _path_is_mode_type KeyboardInterrupt
-------------- Occurrence #4: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module> import abc File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1533, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 486, in _verbose_message KeyboardInterrupt
-------------- Occurrence #5: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module> import abc File "C:\Program Files\Python\Python333\lib\abc.py", line 6, in <module> from _weakrefset import WeakSet File "<frozen importlib._bootstrap>", line 1559, in _find_and_load KeyboardInterrupt
-------------- Occurrence #6: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 69, in search_function def search_function(encoding): KeyboardInterrupt
-------------- Occurrence #7: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module> import abc File "C:\Program Files\Python\Python333\lib\abc.py", line 6, in <module> from _weakrefset import WeakSet File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 584, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 1022, in load_module File "<frozen importlib._bootstrap>", line 1003, in load_module KeyboardInterrupt
-------------- Occurrence #8: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function level=0) File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 584, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 1022, in load_module File "<frozen importlib._bootstrap>", line 1003, in load_module File "<frozen importlib._bootstrap>", line 560, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 857, in _load_module File "<frozen importlib._bootstrap>", line 439, in cache_from_source KeyboardInterrupt
-------------- Occurrence #9: --------------
D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function level=0) File "C:\Program Files\Python\Python333\lib\encodings\cp852.py", line 175, in <module> 0x00ff: 0x00a0, # NO-BREAK SPACE KeyboardInterrupt
On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" <jurko.gospodnetic@pke.hr> wrote:
My scripts replace the default SIGINT/SIGBREAK signal handlers as soon as possible, and everything works great after that, but things get ugly if Ctrl-C is pressed before the script gets a chance to do this. I could even live with an 'exit with an ugly traceback', but having the process hang or fail so that Windows reports it as non-responding or reports it as 'stopped working' and offers to send failure information to Microsoft? That just leaves a bad taste in my mouth. :-(
This sounds like a more troubling variation on the issue raised in issue 14288 (http://bugs.python.org/issue14228). The solution proposed there would appear to be something that would help you, so you might want to chime in on that issue. (I'll be curious to see the responses to the other points you raise.) --David
Hi. On 14.12.2013. 17:14, R. David Murray wrote:
On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" <jurko.gospodnetic@pke.hr> wrote:
My scripts replace the default SIGINT/SIGBREAK signal handlers as soon as possible, and everything works great after that, but things get ugly if Ctrl-C is pressed before the script gets a chance to do this. I could even live with an 'exit with an ugly traceback', but having the
process hang or fail so that Windows reports it as non-responding or
reports it as 'stopped working' and offers to send failure information to Microsoft? That just leaves a bad taste in my mouth. :-(
This sounds like a more troubling variation on the issue raised in issue 14288 (http://bugs.python.org/issue14228). The solution proposed there would appear to be something that would help you, so you might want to chime in on that issue.
Thanks for the tip. I've seen the bug report you mention before, but thought to first inquire about the issue on the mailing list. I'll chime in what I know to the bug report. Final solution proposed there is to add a command-line option to delay enabling current default Python SIGINT handling until after the site.py package has been loaded. That would most likely avoid the startup crashes I mentioned in the original post. On Unix it would make Ctrl-C silently terminate the process if it occurs before default Python signal handling is enabled. I do not know what effect this would have on Windows - possibly the signal would simply be ignored & lost. It would also still leave a slight window between when Python sets up its default SIGINT handling and when user code has a chance to set up its own. My first instinct is to not do that and instead add an option to block SIGINT handling and allow user code to enable its own or default Python handling as it wishes and then unblock SIGINT handling. Note that by 'blocking' a signal I do not mean losing/ignoring it but delaying its handling until signal handling is unblocked. Best regards, Jurko Gospodnetić
Your subject should probably have mentioned Windows. SIGINT handling on UNIX is well-behaved. Yes, you can interrupt a finally clause, but this by itself doesn't threaten the integrity of the interpreter and the standard data types. On Windows, "signal" handling is some feeble emulation done by the C library wrappers and all bets are, as you've discovered, off. My own experience is the opposite of yours -- I often end up with uninterruptable runaway code that can only be stopped by ctrl-BRK, which takes e.g. Powershell with it. :-( That said, I'd be fine with a command-line flag to skip the default SIGINT handler setup. -- --Guido van Rossum (python.org/~guido)
On Sat, 14 Dec 2013 15:14:10 +0100 Jurko Gospodnetić <jurko.gospodnetic@pke.hr> wrote:
I believe the current Python default SIGINT handling by raising an asynchronous KeyboardInterrupt exception is dangerous, and can directly cause Python interpreter crashes even if no user code is involved, or any sort of other 'undefined behaviour' if it is.
It would be nice if you could get an actual C traceback, and open an issue on the bug tracker. Python isn't supposed to crash willy-nilly when Ctrl+C is pressed. (also, which Python version is this?) Regards Antoine.
Hi. On 15.12.2013. 0:19, Antoine Pitrou wrote:
It would be nice if you could get an actual C traceback and open an issue on the bug tracker.
Done. C traceback and related information collected and attached to a new Python issue report available at: http://bugs.python.org/issue19983
Python isn't supposed to crash willy-nilly when Ctrl+C is pressed.
:-D
(also, which Python version is this?)
- Python 3.3.3 (64-bit) downloaded from: http://www.python.org/download/releases/3.3.3 - OS: Windows 7 SP1 x64 - default site.py Hope this helps. Best regards, Jurko Gospodnetić
participants (4)
-
Antoine Pitrou -
Guido van Rossum -
Jurko Gospodnetić -
R. David Murray