[Bug gdb/14135] New: Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[Bug gdb/14135] New: Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

             Bug #: 14135
           Summary: Fails in gdb.python/py-finish-breakpoint.exp when `set
                    target-async on'.
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: qiyao@gcc.gnu.org
    Classification: Unclassified


These fails are mentioned here
http://sourceware.org/ml/gdb-patches/2012-05/msg00290.html.  Track them in this
PR.

Run test suite with async mode, then we can see following fails.

FAIL: gdb.python/py-finish-breakpoint.exp: check MyFinishBreakpoint hit (GDB
internal error)
FAIL: gdb.python/py-finish-breakpoint.exp: check stopped location
FAIL: gdb.python/py-finish-breakpoint.exp: stop in condition function
FAIL: gdb.python/py-finish-breakpoint.exp: stop at conditional breakpoint

Noe that this test case fails (in async mode) when it was introduced by this
commit 7c56fb07bde331d79eb73ece26b8fc960aa13eb2.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[kevin.pouget at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

Kevin Pouget <kevin.pouget at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevin.pouget at gmail dot
                   |                            |com

--- Comment #1 from Kevin Pouget <kevin.pouget at gmail dot com> 2012-05-23 10:27:54 UTC ---
I took a look at this bug, but the python code **seems** not to be directly
involved.

The internal error comes from infrun.c:5973

  if (last.kind == TARGET_WAITKIND_NO_RESUMED)
    {
      gdb_assert (sync_execution || !target_can_async_p ());

      target_terminal_ours_for_output ();
      printf_filtered (_("No unwaited-for children left.\n"));
    }

and it seems to be related to these messages

    linux_nat_wait: [process -1]
    LLW: enter
    LNW: waitpid(-1, ...) returned 0, No child processes
    LLW: exit (no resumed LWP)
    No unwaited-for children left.

coming from linux-nat.c:3689 (linux_nat_wait_1) ... but I have no clue what to
do next ...


Let me know of you have any idea / if there is something I can do

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

--- Comment #2 from Yao Qi <qiyao at gcc dot gnu.org> 2012-05-23 10:39:45 UTC ---
(In reply to comment #1)
> I took a look at this bug, but the python code **seems** not to be directly
> involved.
> 
> The internal error comes from infrun.c:5973
> 
>   if (last.kind == TARGET_WAITKIND_NO_RESUMED)
>     {
>       gdb_assert (sync_execution || !target_can_async_p ());
> 
>       target_terminal_ours_for_output ();
>       printf_filtered (_("No unwaited-for children left.\n"));
>     }
> 
> and it seems to be related to these messages
> 
>     linux_nat_wait: [process -1]
>     LLW: enter
>     LNW: waitpid(-1, ...) returned 0, No child processes
>     LLW: exit (no resumed LWP)
>     No unwaited-for children left.
> 
> coming from linux-nat.c:3689 (linux_nat_wait_1) ... but I have no clue what to
> do next ...
> 
> 
> Let me know of you have any idea / if there is something I can do

The python code is involved in this way, as this backtrace displayed,


(gdb) bt
#0  linux_nat_wait_1 (ops=0x84a2b58, ptid=..., ourstatus=0xbfffe3e4,
target_options=<value optimized out>) at ../../gdb/gdb/linux-nat.c:3821
#1  linux_nat_wait (ops=0x84a2b58, ptid=..., ourstatus=0xbfffe3e4,
target_options=<value optimized out>) at ../../gdb/gdb/linux-nat.c:4074
#2  0x081ec68b in target_wait (ptid=..., status=0xbfffe3e4, options=1) at
../../gdb/gdb/target.c:2624
#3  0x081bae60 in fetch_inferior_event (client_data=0x0) at
../../gdb/gdb/infrun.c:2789
#4  0x081cffa1 in fetch_inferior_event_wrapper (client_data=0x0) at
../../gdb/gdb/inf-loop.c:145
#5  0x081c68cb in catch_errors (func=0x81cff90 <fetch_inferior_event_wrapper>,
func_args=0x0, errstring=0x8365d81 "", mask=6) at
../../gdb/gdb/exceptions.c:546
#6  0x081cfcf3 in inferior_event_handler (event_type=INF_REG_EVENT,
client_data=0x0) at ../../gdb/gdb/inf-loop.c:53
#7  0x081ce4c2 in handle_file_event (data=...) at
../../gdb/gdb/event-loop.c:827
#8  0x081cdb3b in process_event () at ../../gdb/gdb/event-loop.c:401
#9  0x081ce9d6 in gdb_do_one_event () at ../../gdb/gdb/event-loop.c:453
#10 0x08283497 in execute_command (p=0x85beb0e "1", from_tty=0) at
../../gdb/gdb/top.c:492
#11 0x08113354 in execute_gdb_command (self=0x0, args=0x856240c, kw=0x0) at
../../gdb/gdb/python/python.c:453
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


#12 0x0021dca8 in PyCFunction_Call () from /usr/lib/libpython2.6.so.1.0
#13 0x0027e45e in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0
#14 0x0027fcbd in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0
#15 0x00207e97 in ?? () from /usr/lib/libpython2.6.so.1.0
#16 0x001d8edc in PyObject_Call () from /usr/lib/libpython2.6.so.1.0
#17 0x001eae34 in ?? () from /usr/lib/libpython2.6.so.1.0
#18 0x001d8edc in PyObject_Call () from /usr/lib/libpython2.6.so.1.0
#19 0x001de19e in _PyObject_CallMethod_SizeT () from
/usr/lib/libpython2.6.so.1.0
#20 0x08116f20 in gdbpy_should_stop (bp_obj=0x3a6ff4) at
../../gdb/gdb/python/py-breakpoint.c:735
#21 0x08161b4a in bpstat_check_breakpoint_conditions (aspace=0x8547730,
bp_addr=134514268, ptid=..., ws=0xbfffeef4) at ../../gdb/gdb/breakpoint.c:4713
#22 bpstat_stop_status (aspace=0x8547730, bp_addr=134514268, ptid=...,
ws=0xbfffeef4) at ../../gdb/gdb/breakpoint.c:4938
#23 0x081b8b88 in handle_inferior_event (ecs=0xbfffeee4) at
../../gdb/gdb/infrun.c:4227

#24 0x081babb9 in fetch_inferior_event (client_data=0x0) at
../../gdb/gdb/infrun.c:2817
#25 0x081cffa1 in fetch_inferior_event_wrapper (client_data=0x0) at
../../gdb/gdb/inf-loop.c:145
#26 0x081c68cb in catch_errors (func=0x81cff90 <fetch_inferior_event_wrapper>,
func_args=0x0, errstring=0x8365d81 "", mask=6) at
../../gdb/gdb/exceptions.c:546
#27 0x081cfcf3 in inferior_event_handler (event_type=INF_REG_EVENT,
client_data=0x0) at ../../gdb/gdb/inf-loop.c:53
#28 0x081ce4c2 in handle_file_event (data=...) at
../../gdb/gdb/event-loop.c:827
#29 0x081cdb3b in process_event () at ../../gdb/gdb/event-loop.c:401
#30 0x081ce9d6 in gdb_do_one_event () at ../../gdb/gdb/event-loop.c:453
#31 0x08283497 in execute_command (p=0xbffff5f5 "", from_tty=1) at
../../gdb/gdb/top.c:492
#32 0x081c683a in catch_command_errors (command=0x8283330 <execute_command>,
arg=0xbffff5f4 "c", from_tty=1, mask=6) at ../../gdb/gdb/exceptions.c:573
#33 0x081c8b20 in captured_main (data=0xbffff230) at ../../gdb/gdb/main.c:977
#34 0x081c68cb in catch_errors (func=0x81c8090 <captured_main>,
func_args=0xbffff230, errstring=0x8365d81 "", mask=6) at
../../gdb/gdb/exceptions.c:546
#35 0x081c7de2 in gdb_main (args=0xbffff230) at ../../gdb/gdb/main.c:1010
#36 0x08094cf3 in main (argc=20, argv=0xbffff2f4) at ../../gdb/gdb/gdb.c:34


In frame #11, we can see that it tries to execute a command,  in
gdb.python/py-finish-breakpoint.py, we can see a command "where 1" is used in
MyFinishBreakpoint::stop(self) [1],

class MyFinishBreakpoint (gdb.FinishBreakpoint):
    def __init__(self, val, frame):
        gdb.FinishBreakpoint.__init__ (self, frame)
        print "MyFinishBreakpoint init"
        self.val = val

    def stop(self):
        print "MyFinishBreakpoint stop with %d" % int (self.val.dereference ())
        print "return_value is: %d" % int (self.return_value)
        gdb.execute ("where 1") // <-------- [1]
        return True

    def out_of_scope(self):
        print "MyFinishBreakpoint out of scope"

If remove this line [1], internal error goes away.

The doc says "23.2.2.20 Manipulating breakpoints using Python. ... You should
not alter the execution state of the inferior (i.e., step, next, etc.), alter
the current frame context (i.e., change the current active frame), or alter,
add or delete any breakpoint. As a general rule, you should not alter any data
within gdb or the inferior at this time.".  I doubt "where 1" falls in this
category in async mode.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[kevin.pouget at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

--- Comment #3 from Kevin Pouget <kevin.pouget at gmail dot com> 2012-05-23 10:58:17 UTC ---
you're right indeed, I did not notice this part of the execution.

> The doc says "23.2.2.20 Manipulating breakpoints using Python. ... You should
> not alter the execution state of the inferior (i.e., step, next, etc.), alter
> the current frame context (i.e., change the current active frame), or alter,
> add or delete any breakpoint. As a general rule, you should not alter any data
> within gdb or the inferior at this time.".  

> I doubt "where 1" falls in this category in async mode.

I'm not sure to understand your position here: would you like me to change
appropriately "gdb.execute ("where 1")" and fix the testsuite failure, or will
you guys try to fix the underlying problem ?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

--- Comment #4 from Yao Qi <qiyao at gcc dot gnu.org> 2012-05-23 11:12:26 UTC ---
(In reply to comment #3)
> 
> I'm not sure to understand your position here: would you like me to change
> appropriately "gdb.execute ("where 1")" and fix the testsuite failure, or will
> you guys try to fix the underlying problem ?

I am not sure on this either :)  It is good if we can fix the underlying
problem, but don't know how much work it needs.  At the same time, I'd like to
remove "gdb.execute ("where 1")" from test case.  I am not familiar with
gdb/python, but the `stop' method is similar to breakpoint condition, and I
feel it is not right to put gdb.execute (which is similar to breakpoint action)
to it.

Anyway, I'll post a patch to @gdb-patches to see how people there think on
this.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

--- Comment #5 from Yao Qi <qiyao at gcc dot gnu.org> 2012-06-08 13:09:34 UTC ---
Patches are posted http://sourceware.org/ml/gdb-patches/2012-05/msg00963.html

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14135

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com
           Assignee|unassigned at sourceware dot org   |tromey at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14135

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  90e289504f844c162ab2e701f99a309d2b37a62a (commit)
      from  beb460e8d2ddf5327a6ab146055a6e6e9f552a4b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=90e289504f844c162ab2e701f99a309d2b37a62a

commit 90e289504f844c162ab2e701f99a309d2b37a62a
Author: Tom Tromey <tromey@redhat.com>
Date:   Tue Mar 4 11:32:52 2014 -0700

    Fix py-finish-breakpoint.exp with target async.

    With target async enabled, py-finish-breakpoint.exp triggers an
    assertion failure.

    The failure occurs because execute_command re-enters the event loop in
    some circumstances, and in this case resets the sync_execution flag.
    Then later GDB reaches this assertion in normal_stop:

          gdb_assert (sync_execution || !target_can_async_p ());

    In detail:

    #1 - A synchronous execution command is run.  sync_execution is set.

    #2 - A python breakpoint is hit (TARGET_WAITKIND_STOPPED), and the
         corresponding Python breakpoint's stop method is executed.  When
         and while python commands are executed, interpreter_async is
         forced to 0.

    #3 - The Python stop method happens to execute a not-execution-related
         gdb command.  In this case, "where 1".

    #4 - Seeing that sync_execution is set, execute_command nests a new
         event loop (although that wasn't necessary; this is the problem).

    #5 - The linux-nat target's pipe in the event loop happens to be
         marked.  That's normal, due to this in linux_nat_wait:

         /* If we requested any event, and something came out, assume there
            may be more.  If we requested a specific lwp or process, also
            assume there may be more.  */

         The nested event loop thus immediately wakes up and calls
         target_wait.  No thread is actually executing in the inferior, so
         the target returns TARGET_WAITKIND_NO_RESUMED.

    #6 - normal_stop is reached.  GDB prints "No unwaited-for children
         left.", and resets the sync_execution flag (IOW, there are no
         resumed threads left, so the synchronous command is considered
         completed.)  This is already bogus.  We were handling a
         breakpoint!

    #7 - the nested event loop unwinds/ends.  GDB is now back to handling
         the python stop method (TARGET_WAITKIND_STOPPED), which decides
         the breakpoint should stop.  normal_stop is called for this
         event.  However, normal_stop actually works with the _last_
         reported target status:

       void
       normal_stop (void)
       {
        struct target_waitstatus last;
        ptid_t last_ptid;
        struct cleanup *old_chain = make_cleanup (null_cleanup, NULL);

        ...
        get_last_target_status (&last_ptid, &last);

        ...
        if (last.kind == TARGET_WAITKIND_NO_RESUMED)
          {
            gdb_assert (sync_execution || !target_can_async_p ());

            target_terminal_ours_for_output ();
            printf_filtered (_("No unwaited-for children left.\n"));
          }

       And due to the nesting in execute command, the last event is now
       TARGET_WAITKIND_NO_RESUMED, not the actual breakpoint event being
       handled.  This could be seen to be broken in itself, but we can
       leave fixing that for another pass.  The assertion is reached, and
       fails.

    execute_command has a comment explaining when it should synchronously
    wait for events:

          /* If the interpreter is in sync mode (we're running a user
         command's list, running command hooks or similars), and we
         just ran a synchronous command that started the target, wait
         for that command to end.  */

    However, the code did not follow this comment -- it didn't check to
    see if the command actually started the target, just whether the
    target was executing a sync command at this point.

    This patch fixes the problem by noting whether the target was
    executing in sync_execution mode before running the command, and then
    augmenting the condition to test this as well.

    2014-03-20  Tom Tromey  <tromey@redhat.com>

        PR gdb/14135
        * top.c (execute_command): Only dispatch events if the command
        started the target.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog |    6 ++++++
 gdb/top.c     |    4 +++-
 2 files changed, 9 insertions(+), 1 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14135

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.8

--- Comment #7 from Pedro Alves <palves at redhat dot com> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.