[PATCH v4 8/9] fix py-finish-breakpoint.exp with always-async
Pedro Alves
palves@redhat.com
Mon Nov 11 19:51:00 GMT 2013
On 10/22/2013 06:59 PM, Tom Tromey wrote:
> With target async enabled, py-finish-breakpoint.exp will trigger 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 ());
>
> execute_command has a comment explaining why it dispatches 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 started the target, just whether the target was
> executing a sync command at this point.
Can you explain this a little better, please?
IIUC (I haven't really stepped through the code):
- A synchronous execution command is run. sync_execution is set.
- A python breakpoint is hit, and the corresponding stop
method is executed. While python commands are executed,
interpreter_async is forced to 0.
- The Python stop method happens to execute a not-execution-related
gdb command ("where 1").
- Seeing that sync_execution is set, GDB nests a new event loop,
although that wasn't necessary.
- Some event that causes a stop triggers in the inferior, and
normal_stop is called.
- the nested event loop unwinds/ends, and normal_stop is called
again. (IOW, normal_stop was called
twice for the same event.) The assertion triggers.
Is that accurate?
What happens if the Python stop method actually does run an
execution command?
--
Pedro Alves
More information about the Gdb-patches
mailing list