homepage

> 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.