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