[issue8863] Segfault handler: display Python backtrace on segfault

[STINNER Victor]

STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - use more standard function names (_Py_initsegfault => _Py_InitSegfault)
 - use "#ifdef HAVE_SIGACTION" to support system without sigaction(): fallback to signal()
 - usage of the alternative stack is now optional (#ifdef HAVE_SIGALTSTACK)
 - don't call _PyUnicode_AsString() (encode unicode to utf-8) because it allocates memory and it does complex operation which may fail: implement a new simple function to write a unicode string to a FILE* object with ascii+backslashreplace
 - display the function name in the backtrace (but don't display function depth)
 - _Py_FiniSegfault(): restore the old signal handlers before freeing the alternative stack memory (and not the opposite)

I only tested the patch on Linux with a narrow build. It should be tested at least on a wide build and on Windows.

I tested my patch on all Lib/test/crashers/*.py: all segfaults are replaced by nice Python tracebacks.

If you debug a Python program in gdb, gdb stops at the first SIGSEGV (before calling the signal handler).

I didn't tested how the signal handler behaves if it raises a new fault (SIGFPE or SIGSEGV). It is supposes to stop immediatly.

In the worst case, my patch introduces an infinite loop and the program eats all CPU time (and consume maybe a lot of memory?) instead of exiting immediatly. Especially, segfault_handler() doesn't ensure that there is no loop in the frame linked list. A possible solution is to fix a limit of the maximum depth (eg. only display first 100 frames and finished with "...").

----------
Added file: http://bugs.python.org/file19208/segfault_handler-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________