Re: [PATCHv2 1/2] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver

[Pedro Alves <pedro@palves.net>]

On 2022-04-28 12:27, Andrew Burgess via Gdb-patches wrote:
> When running the gdb.mi/mi-exec-run.exp test using the
> native-extended-gdbserver I see failures like this:
> 
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
> 
> There's a race condition here, so you might see a slightly different
> set of failures, but I always see some from the 'run failure detected'
> test.
> 
> NOTE: I also see an additional test failure:
> 
>  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
> 
> but that is a completely different issue, and is not being addressed
> in this commit.
> 
> The problem for the 'run failure detected' test is that we end up
> in gdb_expect looking for output from two spawn-ids, one from
> gdbserver, and one from gdb.  We're looking for one output pattern
> from each spawn-id, and for the test to pass we need to see both
> patterns.
> 
> Now, if gdb exits then this is a test failure (this would indicate gdb
> crashing, which is bad), so we have an eof pattern associated with
> the gdb spawn-id.
> 
> However, in this particular test we expect gdbserver to fail to
> execute the binary (the test binary is set non-executable), and so we
> get an error message from gdbserver (which matches the pattern), and
> then gdbserver exits, this is expected.
> 
> The problem is that after spotting the pattern from gdbserver, we
> often see the eof from gdbserver before we see the pattern from gdb.
> If this happens then we drop out of the gdb_expect without ever seeing
> the pattern from gdb, and fail the test.
> 
> In this commit, I place the spawn-id of gdbserver into a global
> variable, and then use this global variable as the -i option within
> the gdb_expect.
> 
> Now, once we have seen the expected pattern on the gdbserver spawn-id,
> the global variable is cleared.  After this the gdb_expect no longer
> checks the gdbserver spawn-id for additional output, and so never sees
> the eof event.  This leaves the gdb_expect running, which allows the
> pattern from gdb to be seen, and for the test to pass.
> 
> I now see no failures relating to 'run failure detected'.
> ---
>  gdb/testsuite/gdb.mi/mi-exec-run.exp | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)

OK.