https://github.com/python/cpython/blob/master/Modules/faulthandler.c#L240
faulthandler_dump_traceback() is called from the signal handler faulthandler_fatal_error() which needs to be async signal safe and only call async signal safe things...

but faulthandler_dump_traceback calls PyGILState_GetThisThreadState() which ultimately calls thread.c's find_key() which acquires a lock:
 https://github.com/python/cpython/blob/master/Python/thread.c#L208
(*and* calls malloc!)

This sometimes leads to a deadlock when the process is crashing, handled via faulthandler, instead of a crash with stacktrace information printed.  The opposite of the happy debugging experience it is intended to provide.

The _Py_DumpTracebackThreads() code that this calls also calls the same offending function.  Despite having comments alluding to how it is called from within a signal handler.
 https://github.com/python/cpython/blob/master/Python/traceback.c#L754

This is a crashing exception.  Rather than ever deadlock, we should do potentially dangerous things (we're already crashing!).  Most of the time we'll be able to get and display useful information.  On the occasions something bad happens as a result, at least the message printed to stderr before we started trying to do bad things will give a hint as to why the crash reporter crashed.

I _believe_ we always want to use _PyThreadState_UncheckedGet() from the signal handler for the entire codepath.  Effectively a simple read from TLS.  No guarantees possible about the thread state list not in an intermediate state which will trip us up when dumping, but we could never guarantee that anyways.


note: I saw https://bugs.python.org/issue23886 but it only seems quasi related though it is also about getting the thread state.