STINNER Victor <[email protected]> added the comment:
> For fatal errors, you needn't be async-safe, so the fatal error code
> could read fileno(stderr) and give it to the traceback printing code.
My last patch for issue #8863 does exactly that:
##############
void
Py_FatalError(const char *msg)
{
- fprintf(stderr, "Fatal Python error: %s\n", msg);
- fflush(stderr); /* it helps in Windows debug build */
- if (PyErr_Occurred()) {
+ const int fd = fileno(stderr);
+
+ fputs("Fatal Python error: ", stderr);
+ fputs(msg, stderr);
+ fputc('\n', stderr);
+ fflush(stderr);
+
+ if (PyErr_Occurred())
PyErr_PrintEx(0);
+ else {
+ fputc('\n', stderr);
+ fflush(stderr);
+ _Py_DumpBacktrace(fd);
}
...
##############
Yes, call fileno() here is safe.
--
The main problem was on the SIGSEGV handler which was first proposed as enabled
by default. Extract of my old patch:
+static void
+fault_handler(int signum)
+{
+ const int fd = 2; /* should be fileno(stderr) */
+ unsigned int i;
+ fault_handler_t *handler;
...
In the faulthandler module, the last call to faulthandler.enable() saves
sys.stderr.fileno(). If this file descriptor is replaced by a critical file, we
have a problem. It can occurs in two cases:
- stderr was closed (after the call to enable) and a new file gets its file
descriptor number
- dup2() was used
Both cases may occur on a server application.
But I think that everybody agrees to disable the SIGSEGV handler by default.
--
I'm preparing the integration of faulthandler in the following Mercurial repo:
http://hg.python.org/features/faulthandler/
I didn't write the fatal error hook yet.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11393>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
