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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4