Dave Malcolm <dmalc...@redhat.com> added the comment:
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?
- 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.
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
- 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.
Might be nice to also have SIGABRT (as per a c-level assertion failure),
exposed
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?
----------
_______________________________________
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
