Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] testsuite: Fix a racy FAIL on gdb.base/multi-forks.exp
Date: Fri, 13 Mar 2009 21:02:00 -0000	[thread overview]
Message-ID: <20090313194932.GA5597@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20090313161423.GF8368@adacore.com>

On Fri, 13 Mar 2009 17:14:23 +0100, Joel Brobecker wrote:
> That being said, I see later in the same testcase that this problem
> is already handled a different way.

I did not notice before, I agree, patch updated.


> On a side note, I try to avoid delays such as "sleep" like the plague.

I also try when possible.


Thanks,
Jan


gdb/testsuite/
2009-03-13  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix a racy FAIL.
	* gdb.base/multi-forks.exp (continue_to_exit_bp_loc): New function with
	code from `follow parent, print pids'.
	(`follow child, print pids', `follow parent, print pids'): Call it.
	Replace `gdb_test "break..."' by gdb_breakpoint.

--- gdb/testsuite/gdb.base/multi-forks.exp	3 Jan 2009 05:58:03 -0000	1.15
+++ gdb/testsuite/gdb.base/multi-forks.exp	13 Mar 2009 19:43:22 -0000
@@ -51,7 +51,60 @@ global gdb_prompt
 
 # This is a test of gdb's ability to follow the parent, child or both
 # parent and child of multiple Unix fork() system calls.
-#
+
+set exit_bp_loc [gdb_get_line_number "Set exit breakpoint here."]
+
+# Continue till where $exit_bp_loc points at eating all the inferior output
+# which could otherwise corrupt our later communication with GDB.
+
+proc continue_to_exit_bp_loc {} {
+    global exit_bp_loc decimal gdb_prompt
+
+    gdb_breakpoint $exit_bp_loc
+
+    send_gdb "continue\n"
+
+    # The output from the child processes can be interleaved arbitrarily
+    # with the output from GDB and the parent process.  If we don't
+    # consume it all now, it can confuse later interactions.
+    set seen_done 0
+    set seen_break 0
+    set seen_prompt 0
+    set seen_timeout 0
+    while { ($seen_done < 16 || ! $seen_prompt) && ! $seen_timeout } {
+	# We don't know what order the interesting things will arrive in.
+	# Using a pattern of the form 'x|y|z' instead of -re x ... -re y
+	# ... -re z ensures that expect always chooses the match that
+	# occurs leftmost in the input, and not the pattern appearing
+	# first in the script that occurs anywhere in the input, so that
+	# we don't skip anything.
+	gdb_expect {
+	    -re "($decimal done)|(Breakpoint)|($gdb_prompt)" {
+		if {[info exists expect_out(1,string)]} {
+		    incr seen_done
+		} elseif {[info exists expect_out(2,string)]} {
+		    set seen_break 1
+		} elseif {[info exists expect_out(3,string)]} {
+		    set seen_prompt 1
+		}
+		array unset expect_out
+	    }
+	    timeout { set seen_timeout 1 }
+	}
+    }
+
+    if { $seen_timeout } {
+	fail "run to exit 2 (timeout)"
+    } elseif { ! $seen_prompt } {
+	fail "run to exit 2 (no prompt)"
+    } elseif { ! $seen_break } {
+	fail "run to exit 2 (no breakpoint hit)"
+    } elseif { $seen_done != 16 } {
+	fail "run to exit 2 (missing done messages)"
+    } else {
+	pass "run to exit 2"
+    }
+}
 
 # The inferior program builds a tree of processes by executing a loop
 # four times, calling fork at each iteration.  Thus, at each
@@ -66,69 +119,17 @@ global gdb_prompt
 # The result should be that each of the 4 forks returns zero.
 
 runto_main
-set exit_bp_loc [gdb_get_line_number "Set exit breakpoint here."]
-gdb_test "break $exit_bp_loc" "Breakpoint.* at .*" "Break at exit"
-gdb_test "set follow child" "" ""
-
-send_gdb "continue\n"
-gdb_expect {
-    -re ".*Break.* main .*$gdb_prompt.*$" {}
-    -re ".*$gdb_prompt $" {fail "run to exit 1"}
-    default {fail "run to exit 1 (timeout)"}
-}
+gdb_test "set follow child"
+continue_to_exit_bp_loc
 
 gdb_test "print pids" "\\$.* = \\{0, 0, 0, 0\\}.*" "follow child, print pids"
 
 # Now set gdb to follow the parent.
 # Result should be that none of the 4 forks returns zero.
 
-delete_breakpoints
 runto_main
-gdb_test "break $exit_bp_loc" "Breakpoint.* at .*" "Break at exit"
 gdb_test "set follow parent" "" ""
-
-send_gdb "continue\n"
-
-# The output from the child processes can be interleaved arbitrarily
-# with the output from GDB and the parent process.  If we don't
-# consume it all now, it can confuse later interactions.
-set seen_done 0
-set seen_break 0
-set seen_prompt 0
-set seen_timeout 0
-while { ($seen_done < 16 || ! $seen_prompt) && ! $seen_timeout } {
-    # We don't know what order the interesting things will arrive in.
-    # Using a pattern of the form 'x|y|z' instead of -re x ... -re y
-    # ... -re z ensures that expect always chooses the match that
-    # occurs leftmost in the input, and not the pattern appearing
-    # first in the script that occurs anywhere in the input, so that
-    # we don't skip anything.
-    gdb_expect {
-        -re "($decimal done)|(Breakpoint)|($gdb_prompt)" {
-            if {[info exists expect_out(1,string)]} {
-                incr seen_done
-            } elseif {[info exists expect_out(2,string)]} {
-                set seen_break 1
-            } elseif {[info exists expect_out(3,string)]} {
-                set seen_prompt 1
-            }
-            array unset expect_out
-        }
-        timeout { set seen_timeout 1 }
-    }
-}
-
-if { $seen_timeout } {
-    fail "run to exit 2 (timeout)"
-} elseif { ! $seen_prompt } {
-    fail "run to exit 2 (no prompt)"
-} elseif { ! $seen_break } {
-    fail "run to exit 2 (no breakpoint hit)"
-} elseif { $seen_done != 16 } {
-    fail "run to exit 2 (missing done messages)"
-} else {
-    pass "run to exit 2"
-}
+continue_to_exit_bp_loc
 
 gdb_test "print pids\[0\]==0 || pids\[1\]==0 || pids\[2\]==0 || pids\[3\]==0" \
     " = 0" "follow parent, print pids"
@@ -138,7 +139,7 @@ gdb_test "print pids\[0\]==0 || pids\[1\
 #
 
 runto_main
-gdb_test "break $exit_bp_loc" "Breakpoint.* at .*" ""
+gdb_breakpoint $exit_bp_loc
 
 gdb_test "help set detach-on-fork" "whether gdb will detach the child.*" \
     "help set detach"


  reply	other threads:[~2009-03-13 19:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13 16:01 Jan Kratochvil
2009-03-13 16:47 ` Joel Brobecker
2009-03-13 21:02   ` Jan Kratochvil [this message]
2009-03-13 23:11     ` Joel Brobecker
2009-03-14 21:45       ` Jan Kratochvil
2009-03-14 12:32   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090313194932.GA5597@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox