Le vendredi 04 mars 2011 à 06:32 -0500, Scott Dial a écrit :
> On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> > On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
> > <victor.stin...@haypocalc.com> wrote:
> >> So, what do you think?
> >
> > Something we may want to consider is enabling it by default in
> > interactive mode, and also when `-i` is specified on the command line.
>
> I am still bothered by the fact that,
>
> >>> import faulthandler
> >>> faulthandler.enable()
> >>> import sys
> >>> sys.stderr.close()
> >>> sys.stderr = open('logs/error.log', 'wb')
> >>> faulthandler.sigsegv()
>
> , does the wrong thing.
faulthandler.enable() uses sys.stderr by default: it keeps a reference
on this object and stores its descriptor (should be 2). If you close the
file descriptor (eg. sys.stderr.close()), the faulthandler will write
into a closed file, which is not a problem (it doesn't crash or do
something dangerous) except that the backtrace is not displayed.
... in this particulier example, the new opened file (sys.stderr) may
also get the file descriptor 2 (which is a specific value, it is usually
the highest file descriptor at startup on Linux) and so the backtrace
may be written to this file. It is a problem if the new file is a socket
or a critical file. But you enabled explicitly the faulthandler, so you
know what you are doing :-)
> In this incantation, it's easy to say that it's
> programmer error, but I think this still precludes it from being on by
> default (where the first two statement are implicitly executed by the
> interpreter). It's probably uncommon enough to close stderr from an
> interactive interpreter session that it doesn't bother me (although I am
> not sure the utility of that), but I would hesitate to say that is true
> for using '-i'.
I forgot to give my opinion about enabling faulthandler with -i. I vote
-1 because we have to be careful with this new feature and its side
effects. But we may change that later when I will be more confident in
my own code :-)
Your example is a corner case. Having a segfault after changing
sys.stderr in an interpreter is unlikely. Anyway, if someone had such
problem, it is still possible to workaround it. Call again
faulthandler.enable() after changing sys.stderr: the new call to
enable() will just update the file descriptor variable and so the
backtrace is written to the right file.
crier project (similar to faulthandler) creates the
file /tmp/crier-<pid> to dump the backtrace. The tiper projects creates
also a temporary file to dump the backtrace.
But I prefer sys.stderr just because it's enough for me, and I don't
really want to generate a filename or create a new file in the SIGSEGV
handler.
crier dumps the backtrace when a file is created in a specific directory
and tiper dumps the backtrace when a SIGUSR is received. faulthandler
may creates a file after a delay in seconds or on SIGUSR1, but not on a
segmentation fault.
> Otherwise, the functionality seems generally useful and it's on my list
> of things to integrate into my application, and having it in the stdlib
> is one less external dependency for me to manage.
You can already have an optional support of this module. For example:
try:
import faulthandler
except ImportError:
pass
else:
faulthandler.enable()
Integrate it directly into Python should just help users to report more
informations to our bug tracker (don't need to install an extra module
just to report a bug).
Victor
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
