From: Phil Muldoon <pmuldoon@redhat.com>
To: "Ömer Sinan Ağacan" <omeragacan@gmail.com>,
paul_koning <Paul_Koning@dell.com>
Cc: gdb <gdb@sourceware.org>
Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback
Date: Fri, 17 Oct 2014 10:11:00 -0000 [thread overview]
Message-ID: <5440EB39.2060305@redhat.com> (raw)
In-Reply-To: <CAMQQO3kehAHCMQkEOsU8kak5j=CdwZqKEy6_nHubWJF4F3A+Lg@mail.gmail.com>
On 17/10/14 10:30, Ãmer Sinan AÄacan wrote:
> I'm still having this problem. I just tried this:
>
> def handler():
> gdb.execute("continue")
> print "continue returned"
>
> This doesn't print anything, until the script fails with "maximum
> recursion depth". Then it prints lots of "continue returned" lines.
>
> So the problem is `gdb.execute` doesn't immediately return and that's
> causing Python stack to grow, because GDB is calling this function
> without returning anything to previous calls.
>
> I think I need a version of `gdb.execute` that returns immediately.
> ie. async version or something like that. Is such a thing possible?
>
> Thanks again.
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.
A workaround would be to post any gdb.execute statements into the GDB
event loop. See gdb.post_event. That will return immediately and the
gdb.execute function will be scheduled to be called in the event loop.
Note there is no guarantee when this is. But as long as GDB is not
busy processing other events it usually means right away.
I'll work on posting that GIL patch soon.
Cheers
Phil
next prev parent reply other threads:[~2014-10-17 10:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 10:46 Ömer Sinan Ağacan
2014-10-16 12:45 ` Phil Muldoon
2014-10-16 14:28 ` Paul_Koning
[not found] ` <CAMQQO3=GxjGzF-9RXQsJ_9=Du3rS-UoYFA_0-friPp1nMa8yAA@mail.gmail.com>
2014-10-16 15:04 ` Paul_Koning
2014-10-16 15:15 ` Ömer Sinan Ağacan
2014-10-16 15:18 ` Ömer Sinan Ağacan
2014-10-17 9:31 ` Ömer Sinan Ağacan
2014-10-17 10:11 ` Phil Muldoon [this message]
2014-10-17 10:53 ` Ömer Sinan Ağacan
2014-10-17 14:20 ` Phil Muldoon
2014-10-17 14:27 ` Ömer Sinan Ağacan
2014-10-17 15:02 ` Phil Muldoon
2014-10-17 15:04 ` Paul_Koning
2014-10-17 17:31 ` Phil Muldoon
2014-10-17 16:41 ` Doug Evans
2014-10-17 17:35 ` Phil Muldoon
2014-10-17 16:45 ` Doug Evans
[not found] ` <543FE072.6040507@redhat.com>
2014-10-16 15:16 ` Ömer Sinan Ağacan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5440EB39.2060305@redhat.com \
--to=pmuldoon@redhat.com \
--cc=Paul_Koning@dell.com \
--cc=gdb@sourceware.org \
--cc=omeragacan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox