Re: [PATCH v4 8/9] fix py-finish-breakpoint.exp with always-async

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

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

Pedro> Can you explain this a little better, please?

We'll see :)

Pedro> IIUC (I haven't really stepped through the code):

Pedro>  - A synchronous execution command is run.  sync_execution is set.

Pedro>  - A python breakpoint is hit, and the corresponding stop
Pedro>    method is executed.  While python commands are executed,
Pedro>    interpreter_async is forced to 0.

Pedro>  - The Python stop method happens to execute a not-execution-related
Pedro>    gdb command ("where 1").

Pedro>  - Seeing that sync_execution is set, GDB nests a new event loop,
Pedro>    although that wasn't necessary.

Pedro>  - Some event that causes a stop triggers in the inferior, and
Pedro>    normal_stop is called.

Ok to here.  And this step is where I think the bug lies -- the comment
in execute_command explains the logic here, but the code doesn't
faithfully implement it.

Pedro>  - the nested event loop unwinds/ends, and normal_stop is called
Pedro>    again.  (IOW, normal_stop was called
Pedro>    twice for the same event.)  The assertion triggers.

I think the event is not handled twice.  Instead the second time the
event is TARGET_WAITKIND_NO_RESUMED:

    infrun: target_wait (-1, status) =
    infrun:   -1 [process -1],
    infrun:   status->kind = no-resumed
    infrun: TARGET_WAITKIND_NO_RESUMED
    infrun: stop_stepping
    No unwaited-for children left.
    infrun: BPSTAT_WHAT_STOP_NOISY
    infrun: stop_stepping

Pedro> Is that accurate?

Pedro> What happens if the Python stop method actually does run an
Pedro> execution command?

I can find out -- but note that we explicitly disavow this in the
manual, so in a sense it doesn't matter.

Tom