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

Tom Tromey
2013-12-09T17:53:00Z

>>>>> "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