Message206282
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(). |
|
Date |
User |
Action |
Args |
2013-12-16 09:02:29 | vstinner | set | recipients:
+ vstinner, tim.peters, pitrou, tim.golden, brian.curtin, Jurko.Gospodnetić |
2013-12-16 09:02:29 | vstinner | set | messageid: <1387184549.18.0.248908328227.issue19983@psf.upfronthosting.co.za> |
2013-12-16 09:02:29 | vstinner | link | issue19983 messages |
2013-12-16 09:02:27 | vstinner | create | |
|