[issue11393] Integrate faulthandler module into Python 3.3

[Dave Malcolm]

Dave Malcolm <dmalcolm at 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 <report at bugs.python.org>
<http://bugs.python.org/issue11393>
_______________________________________