Scott Dial <sc...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue8863> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
