Hi Victor,
> I understand that you are writing a debugger and you can only *read*
> modify, not execute code, right?
I'm working on a frame stack sampler that runs independently from the
Python process. The project is "Austin"
(
https://github.com/P403n1x87/austin). Whilst I could, in principle,
execute code with other system calls, I prefer not to in this case.
> 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..
I would like my application to make as few assumptions as possible.
The _PyRuntime symbol might not be available if all the symbols have
been stripped out of the binaries. That's why I was trying to rely on
_PyThreadState_Current, which is in the .dynsym section. Judging by
the output of nm -D `which python3` (I'm on Python 3.6.6 at the
moment) I cannot see anything more useful than that.
My current strategy is to try and make something out of this symbol
and then fall back to a brute force approach to scan the .bss section
for valid PyInterpreterState instances (which works reliably well and
is quite fast too, but a bit ugly).
> 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 :-)
Yes thanks! Your comment made me realise why I can use
PyThreadState_Current at the very beginning, and it is because Python
is going through the intensive startup process, which involves, among
other things, the loading of frozen modules (I can clearly see most if
not all the steps in the output of Austin, as mentioned in the repo's
README). During this phase, the main (and only thread) holds the GIL
and is quite busy doing stuff. The long-running applications that I
was trying to attach to have very long wait periods where they sit
idle waiting for a timer to trigger the next operations, that fire
very quickly and put the threads back to sleep again.
If this is what the _PyThreadState_Current is designed for, then I
guess I cannot really rely on it, especially when attaching Austin to
another process.
Best regards,
Gabriele