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