Re: [RFC - Python] New ObjFile event & GDB Async

[Phil Muldoon <pmuldoon at redhat dot com>]

Kevin Pouget <kevin.pouget@gmail.com> writes:

> On Thu, Sep 1, 2011 at 1:00 PM, Kevin Pouget <kevin.pouget@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 12:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> A new problem showed up with this patch, which make it crash certainly
> because of the async mode.

Ugh :(


> However, when I want to execute `gdb.execute("some function")` during
> the callback, the execution ends up in:
>
> #0  0x... in poll () from /lib64/libc.so.6
> #1  0x... in gdb_wait_for_event (block=1)    at gdb/event-loop.c:864
> #2  0x... in gdb_do_one_event ()    at gdb/event-loop.c:462
> #3  0x... in execute_command (p=0x1bd5e2c "off", from_tty=0)    at
> gdb/gdb/top.c:452
> #4  0x... in execute_gdb_command (self=0x0, args=0x..., kw=0x0)    at
> gdb/python/python.c:395
> #5 ... python backtrace
>
> because of this condition in top.c:
> // gdb.execute("some function") was "set confirm off"
> // interpreter_async = 0
> // sync_execution = 1
> 450	      if (!interpreter_async && sync_execution)
> 451		{
> 452		  while (gdb_do_one_event () >= 0)
> 453		    if (!sync_execution)
> 454		      break;
>
> This is in opposition with the 'stop' event where every thing is ok and
> // interpreter_async = 0
> // sync_execution = 0

I'm not sure on the full intricacies of async mode.  Maybe we should run
the Python tests with it on and off in the testsuite to expose issues
like this.

I don't believe there is any parallel to the acquisition of the Python global
interpreter lock in GDB.  Maybe Pedro knows the solution?

Cheers,

Phil