faulthandler_dump_traceback is not async signal safe - called from signal handler

[gpshead]

https://github.com/haypo/faulthandler/blob/master/faulthandler.c#L254

but is called from the signal handler. this tries to acquire a lock via PyGILState_GetThisThreadState() which ultimately calls into Python's thread.c which uses PyThread_acquire_lock(_Py_thread_keymutex) and later calls malloc() (which also uses locks).

This can lead to deadlocks when crashing instead of a stacktrace.

[vstinner]

faulthandler is now part of CPython, please reports issues at http://bugs.python.org/ ;-)

[gpshead]

I really should know that. :) https://bugs.python.org/issue30165

[vstinner]

According to http://bugs.python.org/issue30165 this issue only impacts the backport, not the stdlib implementation. I started by documenting differences between backport and stdlib implementations:
https://faulthandler.readthedocs.io/#differences-with-stdlib-faulthandler

[vstinner]

On CPython 2.7, PyGILState_GetThisThreadState() uses a lock and so is not signal safe. To prevent the risk of race condition, there are two options:

• Always dump all threads and loose the "Current thread" information
• Use PyThreadState_Get() which means that "Current thread" is the thread holding the GIL which can be different than the thread which caused the fault (got the signal).

What do you think @gpshead ?