faulthandler was enhanced in Python 3.6: * Issue #26563: faulthandler now works in non-Python threads. * Issue #26154: Issue #26154: Add a new private _PyThreadState_UncheckedGet() function which gets the current thread state, but don't call Py_FatalError() if it is NULL. Can you please try Python 3.6 (default branch of Mercurial) with your use case to check if the issue is solved? And also Python 3.5 (3.5 branch of Mercurial)? I can try to backport some enhancements from Python 3.6 to Python 3.5 if needed. If it's ok for you, I will then port changes to the GitHub project. Note: I also add new unit tests. > SIGUSR1/2 will get delivered to any running thread. The current thread of the signal doesn't give any useful information. Try to get the current Python thread which holds the GIL instead, or use NULL. I don't understand your usecase, since faulthandler displays *all* Python threads by default. all_threads=True in faulthandler.register(signum, file=sys.stderr, all_threads=True, chain=False): https://docs.python.org/dev/library/faulthandler.html#faulthandler.register
PyGILState_GetThisThreadState might not be the same Python thread as _PyThreadState_Current, even in the case that both are not NULL. That is because SIGUSR1/2 will get delivered to any running thread. In the output by faulthandler, I want that it marks the current Python thread correctly, and not the current sighandler thread.
> I want that it marks the current Python thread correctly, and not the current sighandler thread. Oooooook, I finally understood your use case. You want to know which threads hold the GIL. You don't care which thread got the signal.
Yes exactly. Sorry if I was unclear before. :) I mentioned SIGUSR1/2 because for a segfault, the signal handler will usually be executed in the same thread (although I'm not sure if that is guaranteed), so that was usually not a problem. But I used SIGUSR1 when my Python application is hanging and esp in that case I would like to know the current Python active thread.
