[Python-Dev] What is the purpose of the _PyThreadState_Current symbol in Python 3?

Victor Stinner vstinner at redhat.com
Thu Sep 27 16:44:37 EDT 2018


Le mer. 26 sept. 2018 à 23:27, Gabriele <phoenix1987 at gmail.com> a écrit :
> In trying to find the location of a valid instance of PyInterpreterState in the virtual memory of a running Python (3.6) application (using process_vm_read on Linux),

I understand that you are writing a debugger and you can only *read*
modify, not execute code, right?

> I have noticed that I can only rely on _PyThreadState_Current.interp at the very beginning of the execution. If I try to attach to a running Python process, then _PythreadState_Current.interp doesn't seem to point to anything useful to derive the currently running threads and the frame stacks for each of them.

In the master branch, it's now _PyRuntime.gilstate.tstate_current. If
you run time.sleep(3600) and look into
_PyRuntime.gilstate.tstate_current using gdb, you can a NULL pointer
(tstate_current=0) because Python releases the GIL..

In faulthandler, I call PyGILState_GetThisThreadState() from signal
handlers to get the Python thread state of the current thread... But
this one is implemented using PyThread_tss_get()
(pthread_getspecific() on most platforms). Moreover, it returns NULL
if the current thread is not a Python thread.

There is also _PyGILState_GetInterpreterStateUnsafe() which gives
access to the current Python interpreter:
_PyRuntime.gilstate.autoInterpreterState. From the interpreter, you
can use the linked list of thread states from interp->tstate_head.

I hope that I helped :-)

Obviously, when you access Python internals, the details change at
each Python release... I described the master branch.


More information about the Python-Dev mailing list