[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor
report at bugs.python.org
Mon Mar 21 17:54:45 CET 2011
STINNER Victor <victor.stinner at haypocalc.com> added the comment:
Le lundi 21 mars 2011 à 15:59 +0000, Dave Malcolm a écrit :
> Various thoughts/nitpicking:
> - is it possible to indicate with a coding convention (e.g.
> comments) which parts of the code are intended to be called from a
> signal handler? It seems worth making this explicit. Or perhaps put
> it all in one file?
Ok, good idea, I will do that. I think that I will write it in the
function comment, something like: "This function is signal safe".
The following functions are signal safe:
faulthandler_fatal_error()
faulthandler_dump_backtrace()
faulthandler_dump_backtrace_threads()
faulthandler_user()
(.. and all helper functions, used by faulthandler_dump_backtrace():
reverse_string(), dump_decimal(), dump_hexadecimal(), dump_ascii(),
dump_frame().)
> - within tests.py, check_enabled and check_disabled seem to me to be
> misnamed; it's not at all clear what they do.
> I'd suggest renaming "get_output" to "run_code", perhaps (adding
> a docstring specifying the returned value)
> "check_enabled" seems to mean "assertCodeLeadsToOutput" or
> somesuch.
Ok, I will try to find better names.
> Within backtrace.py:
> - do all platforms supported by Python have a concept of numeric
> filedescriptors? I was wondering if FILE* might be a better
> abstraction here (with flushing), then read
> http://bugs.python.org/issue8863#msg124385 which gives the reason:
> fprintf etc are not signal-safe
Yes, I think that all platforms support numeric file descriptors. On
Windows, numeric file descriptors are not the native type for file, but
Windows provides a POSIX API.
And yes, FILE* API cannot be used because it uses buffers, and buffers
are not signal safe (at least, fwrite() is not signal safe).
I tested my module on Linux, FreeBSD and Windows. I don't have other
OS :-)
> - all of the calls to "write" ignore the return code, leading to
> warnings from GCC. I don't think there's any good way to handle
> errors from these calls, though.
Except exiting the signal handler, I don't see anything useful to do on
write() error. I think that it is safe to ignore write() errors, and I
prefer to keep the code simple.
I don't know how to make these warnings quiet.
> Might be nice to also have SIGABRT (as per a c-level assertion
> failure), exposed
I think that it would do that while integrating faulthandler into Python
to check the interaction with Py_FatalError().
> NB: on Fedora/RHEL we also have a whole-system crash detection system
> (called "abrt": https://fedorahosted.org/abrt/ ), and in theory, that
> means that for me, crash reports get run using the gdb pretty-print
> hooks.
>
> I'm wondering to what extent this would interract with whole-system
> crash-detection tools: would it e.g. mask a SIGSEGV, so that the crash
> is not seen by that system?
faulthandler is compatible with gdb and abrt. For gdb, you get the
SIGSEGV signal before faulthandler: the "signal SIGSEGV" gdb command
will call faulthandler signal handler. For abrt, faulthandler does print
the backtrace, and then abrt is called. Execution order:
crash => gdb => faulthandler => abrt
(I think that gdb and abrt are exclusive)
I didn't try abrt, but I tried Ubuntu Apport which is smiliar (Apport
uses /proc/sys/kernel/core_pattern with a pipe).
You may test faulthandler on Fedora to tell me if it interacts correctly
with abrt :-)
https://github.com/haypo/faulthandler/wiki/
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11393>
_______________________________________
More information about the Python-bugs-list
mailing list