public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver
@ 2022-05-03  9:48 Andrew Burgess
  0 siblings, 0 replies; only message in thread
From: Andrew Burgess @ 2022-05-03  9:48 UTC (permalink / raw)
  To: gdb-cvs

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a56c63f78ebd158972882b4f8c183d70e9ef1cfd

commit a56c63f78ebd158972882b4f8c183d70e9ef1cfd
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Wed Apr 27 15:40:39 2022 +0100

    gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver
    
    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'.

Diff:
---
 gdb/testsuite/gdb.mi/mi-exec-run.exp | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp
index f397159078f..ffbe6bcd36e 100644
--- a/gdb/testsuite/gdb.mi/mi-exec-run.exp
+++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp
@@ -93,10 +93,27 @@ proc test {inftty_mode mi_mode force_fail} {
 	set test "run failure detected"
 	send_gdb "-exec-run --start\n"
 
+	# Redirect through SPAWN_LIST global.  If the
+	# inferior_spawn_id is not the same as gdb_spawn_id, e.g. when
+	# testing with gdbserver, the gdbserver can exit after
+	# emitting it's error message.
+	#
+	# If inferior_spawn_id exits then we may see the eof from that
+	# spawn-id before we see the pattern from the gdb_spawn_id,
+	# which will kick us out of the gdb_expect, and cause us to
+	# fail the test.
+	#
+	# Instead we clean SPAWN_LIST once we've seen the expected
+	# pattern from that spawn-id, and after that we no longer care
+	# when gdbserver exits.
+	global spawn_list
+	set spawn_list "$inferior_spawn_id"
+
 	gdb_expect {
-	    -i "$inferior_spawn_id"
+	    -i spawn_list
 	    -re ".*Cannot exec.*Permission denied" {
 		set saw_perm_error 1
+		set spawn_list ""
 		verbose -log "saw perm error"
 		if {!$saw_mi_error} {
 		    exp_continue


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-05-03  9:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-03  9:48 [binutils-gdb] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver Andrew Burgess

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).