This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] testsuite: Fix a racy FAIL on gdb.base/multi-forks.exp
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 13 Mar 2009 09:14:23 -0700
- Subject: Re: [patch] testsuite: Fix a racy FAIL on gdb.base/multi-forks.exp
- References: <20090313152723.GA13673@host0.dyn.jankratochvil.net>
I am not very familiar with this testcase, so please consider this
as an informal review. I started looking at this just because I was
actually wondering about the availability of "close"....
> Instead of the output suppression by `close (1)' some sleep would also fix it
> if close (1) is not compatible enough.
As far as I can tell, "close" is POSIX, so should be fairly portable.
I'm not entirely sure about Windows, but I do think it's available.
The symbol name might be _close, though.
That being said, I see later in the same testcase that this problem
is already handled a different way. Basically, we know that the
inferiors are going to print a bunch of traces, so we just wait
for all of them to be printed before we do the next test:
# 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 }
}
}
Would it make sense to do the same in the case where we follow
the child?
On a side note, I try to avoid delays such as "sleep" like the plague.
A one or two second delay on its own is not that bad, but they tend
to add-up pretty quickly. Since our testsuite is sequential, it's time
wasted doing nothing. So I only use them if I don't have any other choice.
--
Joel