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

[Kevin Pouget <kevin dot pouget at gmail dot com>]

On Wed, Sep 28, 2011 at 9:29 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
> 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?

I'm not sure about what you mean by "acquisition of the Python global
interpreter lock", but I took another look at this bug, and I could
notice that the bug is actually already present in the current GDB
(20110919 at least).

this little script:

define highlight_sync_execution_bug
  break $arg0
  commands
    silent
    if sync_execution != 1
      cont
    else
      printf "#####################\n"
      where 1
    end
  end
end

highlight_sync_execution_bug python_on_resume

highlights that among theses observers:

  observer_attach_new_thread (add_thread_object);
  observer_attach_thread_exit (delete_thread_object);
  observer_attach_normal_stop (python_on_normal_stop);
  observer_attach_target_resumed (python_on_resume);
  observer_attach_new_objfile (python_new_objfile);
  observer_attach_inferior_exit (python_inferior_exit);

only `observer_attach_target_resumed' and
`observer_attach_new_objfile' are broken (the last one is related to
my patch), and indeed, in async-mode:

def toto(event):
	gdb.execute("set confirm off")
	print "-------------><------------"	

gdb.events.cont.connect(toto)


fails:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 13993]
0x0000003c47a016b0 in ?? ()
-------------><------------

(it doesn't crash the same way though, so I can't be sure it's the
same bug ... !)

Let me know what you think about it


cordially,

Kevin