This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 20 Mar 2014 18:22:26 +0000
- Subject: [Bug gdb/14135] Fails in gdb.python/py-finish-breakpoint.exp when `set target-async on'.
- Auto-submitted: auto-generated
- References: <bug-14135-4717 at http dot sourceware dot org/bugzilla/>
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.