This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: faulthandler_user should use _PyThreadState_Current
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.6, Python 3.4, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Albert.Zeyer, vstinner
Priority: normal Keywords:

Created on 2015-04-08 08:03 by Albert.Zeyer, last changed 2022-04-11 14:58 by admin.

Messages (5)
msg240252 - (view) Author: Albert Zeyer (Albert.Zeyer) * Date: 2015-04-08 08:03
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 have patched this for the external faulthandler module here:
https://github.com/haypo/faulthandler/pull/12
https://github.com/albertz/faulthandler/commit/dc92265
msg262252 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-03-23 09:23
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
msg262253 - (view) Author: Albert Zeyer (Albert.Zeyer) * Date: 2016-03-23 09:34
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.
msg262469 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-03-25 23:52
> 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.
msg262476 - (view) Author: Albert Zeyer (Albert.Zeyer) * Date: 2016-03-26 00:13
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.
History
Date User Action Args
2022-04-11 14:58:15adminsetgithub: 68074
2016-03-26 00:13:55Albert.Zeyersetmessages: + msg262476
2016-03-25 23:52:52vstinnersetmessages: + msg262469
2016-03-23 09:34:41Albert.Zeyersetmessages: + msg262253
2016-03-23 09:23:14vstinnersetmessages: + msg262252
2015-04-09 05:24:34ned.deilysetnosy: + vstinner
2015-04-08 08:03:04Albert.Zeyercreate