STINNER Victor <victor.stin...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue11393> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com