Hi, Le mer. 26 sept. 2018 à 23:27, Gabriele <phoenix1...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
