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"
next prev parent 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