New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When interrupted during startup, Python should not call abort() but exit() #64182
Comments
If you press Ctrl-C during Python startup on Windows you may get interpreter crashes with different Python tracebacks displayed on the standard system error output stream. Reproduced using:
To reproduce simply run the Python interpreter with a prepared Python script as input and press Ctrl-C immediately afterwards. Possible results:
I'm attaching more detailed information on specific crash instances. For some more information & background see the devel mailing list thread started at: 'https://mail.python.org/pipermail/python-dev/2013-December/130750.html'. |
I can reproduce this most easily if I run a command like: clean.cmd & run.py where clean.cmd is any short batch script and run.py is a file containing only the '#! python3' shabang line. The batch script in front is not necessary, and I've originally been reproducing the issue without it, but the problem seems much easier to reproduce with it, most likely because is slightly delays the Python startup and thus makes it easier for the Ctrl-C signal to kick in early enough during Python startup. |
I reproduced the issue about 10 more times to see if I'd get some more useful C tracebacks in Visual Studio, but they seems to be the pretty much the same every time (as seen in the attached http://bugs.python.org/file33137/crash-info-10.txt file). I'm attaching another one, just for the record. The only difference I see between crash #10 and this one is that second thread has a bit different name, but that is most likely just some internal Windows API worker thread and not something explicitly started by Python or relevant to this report. |
Ah, ok. So it's a controlled crash: Python fails initializing the standard streams and so it decides to bail out (by using Py_FatalError, since Py_Initialize doesn't return an error code). What we could do is call initsigs() after initstdio() (but still before initsite(), since initsite() can call arbitrary Python code). I'm a bit surprised that you manage to press Ctrl-C so fast that it occurs right during initialization of standard streams, by the way :-) |
I modified initstdio() to add raise(SIGINT); at the beginning of the function. I get: $ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 2157, in _find_and_load
KeyboardInterrupt
Abandon (core dumped) You can also inject SIGINT in gdb if you set a breakpoint on initstdio(): (gdb) b initstdio I don't consider this as a bug, but I understand that you would prefer a different behaviour. The question is which behaviour do you want? You want to ignore CTRL+c during initialization? Do you prefer to quit without calling abort(), ex: exit with exit code 1? Maybe we should modify Py_FatalError() to call exit(1) in release mode, and only call abort() in debug mode? Dumping a core dump, opening a Windows fatal error popup, calling Fedora ABRT handler, etc. is maybe not very useful, especially for the KeyboardInterrupt case.
initfsencoding() calls also Python code. It loads at least 3 Python scripts: encodings/init.py, encodings/aliases.py and encodings/NAME.py where NAME is your locale encoding. IMO signal handlers should be set up before any Python code is loaded, so initsigs() should be called before initfsencoding(). |
On 16.12.2013 10:02, STINNER Victor wrote:
I don't think changing Py_FatalError() is a good idea. However, Python should simply exit with an error code in such a case; which then The fatal error is reserved for cases where you cannot continue |
2013/12/16 Marc-Andre Lemburg <report@bugs.python.org>:
Before exiting, you need a message. If there is also an exception, you If the defaullt behaviour of Py_FatalError() cannot be modified, a new Example: a new private function "void initerror(const char *message)" |
On 16.12.2013 10:30, STINNER Victor wrote:
Sounds reasonable. BTW: Why can't we make this an official API function, e.g. |
Exiting Python immediatly is bad practice, there is already Py_FatalError() for that. Instead of adding a second public function, I would prefer to remove most calls to Py_FatalError() and write nicer error handlers :-) |
init_error.patch: modify Py_Initialize() to exit with exit(1) instead of abort(), to not call the sytem fault handler (ex: dump a coredump on Linux, or open a popup on Windows). The patch calls also initsigs() before initfsencoding(), because initfsencoding() may call Python code (encodings implemented in Python). Example with gdb (to simulate a CTRL+c during Python startup): $ gdb ./python
(gdb) b initfsencoding
(gdb) run
Breakpoint 1, initfsencoding (interp=0x971420) at Python/pythonrun.c:972
(gdb) signal SIGINT
(gdb) cont
Python initialization error: Unable to get the locale encoding
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 2152, in _find_and_load
KeyboardInterrupt
[Inferior 1 (process 15566) exited with code 01] The process exited with exit code 1, not with SIGABRT. |
Anyone have an eye on this item? P.S. |
err... by Python 3.5 I meant Python 3.4.1 as well :-) |
What you did is just right. The offer to help move things along is One thing you can do is determine which patch (likely the most recent Another thing you can do is see if there are any outstanding review Finally, you could review the patch yourself through the same link. Posting to the core-mentorship list FYI, we've been working on a comprehensive guide to our development |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: