[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[Scott Dial]

Scott Dial <scott at scottdial.com> added the comment:

On 12/20/2010 8:30 AM, STINNER Victor wrote:
> Write into a closed file descriptor just does nothing. Closed file descriptors 
> are not a problem.

My issue not with a closed file descriptor, it is with an open file
descriptor that is not what you think it is.

>> For all you know, fd=2 currently is a network socket that you
>> will be throwing gibberish at, or worse it could be a block device that
>> you are writing gibberish on.
> 
> The GNU libc has also a fault handler (source code: debug/segfault.c). It uses 
> the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is 
> set (value stored in "fname" variable): open the specified file.

The GNU libc segfault handler is *opt-in* via the SEGFAULT_SIGNALS
environment variable. I do not know of a system where SEGFAULT_SIGNALS
is a part of the default environment. I suspect the only time anyone
uses that variable and code is if they are using the "catchsegv" tool,
which comes with glibc. In any case, that developer should be aware of
the implication of closing fd 2.

> The FILE* type cannot be used because fprintf(), fputs(), ... are not signal-
> safe.

My point was that in C++, they have an object that an application
developer more readily associates with "stderr" than fd 2. That writing
to "stderr" leads to a write to fd 2 is incidental, because it's
possible that "stderr" does *not* lead to a write to fd 2 and that
writing to fd 2 would be a bad thing to do blindly. For instance, you
can call freopen(path, mode, stderr) and fd 2 will end up closed and
another fd will be the target of stderr. I don't believe POSIX
guarantees that open() will not re-use fd 2.

> The problem is to detect that stderr file descriptor changes (eg. closed, 
> duplicated, reopened, etc.). I don't think that it's possible to detect such 
> changes (with a portable function).

When I said that, I hadn't fully investigated the intricacies of the io
types. I was unaware that you could assign to "sys.stderr.buffer.raw"
and change out the target fd. I assumed a BufferedWriter could not have
the target stream changed out from beneath it. So, I don't have a
solution to the problem of knowing the correct (if any) file descriptor
to write to.

If the argument is made that fd 2 is the right place for most Python
applications, then there needs to be a programmatic way to disable this
feature and/or tell it where to write, so that programs that daemonize
can do the right thing.

----------
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV,	SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________