This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: recursion limit exceeded in Python API, but there's only one function in traceback
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Paul_Koning at dell dot com
- Cc: omeragacan at gmail dot com, gdb at sourceware dot org
- Date: Fri, 17 Oct 2014 18:31:07 +0100
- Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback
- Authentication-results: sourceware.org; auth=none
- References: <CAMQQO3knCrj=7dQNV1NEJofLhm7gZzvzG55K66uDOJt7qYrjGg at mail dot gmail dot com> <543FBDFF dot 3050709 at redhat dot com> <104DEFBD-D686-4290-8E3C-725A51C165E6 at dell dot com> <CAMQQO3=GxjGzF-9RXQsJ_9=Du3rS-UoYFA_0-friPp1nMa8yAA at mail dot gmail dot com> <7BB30632-15BE-4EF8-B84F-D35A27772F18 at dell dot com> <CAMQQO3kAPanS0uPPjUjiTFjpkOKUR5CiV55BJMbbA2p_J7d3nQ at mail dot gmail dot com> <CAMQQO3kehAHCMQkEOsU8kak5j=CdwZqKEy6_nHubWJF4F3A+Lg at mail dot gmail dot com> <5440EB39 dot 2060305 at redhat dot com> <2BD7D737-CFF3-4368-9265-25C6611CF40C at dell dot com>
On 17/10/14 16:04, Paul_Koning@dell.com wrote:
>
> On Oct 17, 2014, at 6:11 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
>> ...
>> Right. gdb.execute won't return until the command has completed.
>> Also the Python GIL has been acquired (as this is coming from the
>> Python interpreter) and so now Python is also blocked too. So in
>> effect the only thing running at this point is the gdb.execute command
>> that was invoked (in your case, the continue command). That will
>> return, and then the Python GIL will be released and the rest of the
>> script will continue.
>>
>> I have a patch I need to upstream that adds a release_gil keyword to
>> gdb.execute. This optionally releases the GIL before executing the
>> command. But I have not got around to that yet.
>
> Could you explain why gdb.execute should ever hold onto the GIL while performing the command? I view gdb.execute as akin to an I/O operation, which releases the GIL around the I/O. Another way to look at it is that execute is performing a GDB command. Either that isn’t a Python operation — in which case the GIL is not needed since the data it protects won’t be touched. Or it is a command that (possibly indirectly) invokes another Python operation — in which case the GIL has to be released or you end up with a deadlock.
>
It (GDB) is not holding the GIL, Python is. The gdb.execute call at that
point has been called from the Python interpreter, and it has managed
the GIL until that point.
This means in current behavior, say you had three threads running,
they are all suspended during the call to gdb.execute. A user
submitted a request that we release the GIL (even though GDB did not
acquire it). The patch that I will submit (soon) just releases the GIL
so that on long-lived operations Python threads can still continue to
execute. It does this with SaveThread/RestoreThread. There is more
detail on this in the bugzilla posted.
Cheers
Phil