[issue19983] Ctrl-C at startup can end in a Py_FatalError call
STINNER Victor
report at bugs.python.org
Mon Dec 16 10:02:29 CET 2013
STINNER Victor added the comment:
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
(gdb) run
<python stopped at initstdio enter>
(gdb) signal SIGINT
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.
> What we could do is call initsigs() after initstdio() (but still before initsite(), since initsite() can call arbitrary Python code).
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().
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________
More information about the Python-bugs-list
mailing list