[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
Hi,
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.
Victor
More information about the Python-Dev
mailing list