From: Junio C Hamano <gitster@pobox.com>
To: larsxschneider@gmail.com
Cc: git@vger.kernel.org, sunshine@sunshineco.com,
sschuberth@gmail.com, Matthieu.Moy@grenoble-inp.fr,
avila.jn@gmail.com, luke@diamand.org, dturner@twopensource.com
Subject: Re: [PATCH v4 1/4] add function test_must_fail_or_sigpipe and use it to fix flaky tests
Date: Fri, 06 Nov 2015 10:27:02 -0800 [thread overview]
Message-ID: <xmqqr3k32dc9.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1446800323-2914-2-git-send-email-larsxschneider@gmail.com> (larsxschneider@gmail.com's message of "Fri, 6 Nov 2015 09:58:40 +0100")
larsxschneider@gmail.com writes:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is
> flaky in the following case:
> 1. remote upload-pack finds out "not our ref"
> 2. remote sends a response and closes the pipe
> 3. fetch-pack still tries to write commands to the remote upload-pack
> 4. write call in wrapper.c dies with SIGPIPE
>
> t5504 "9 - push with transfer.fsckobjects" is flaky, too, and returns
> SIGPIPE once in a while. I had to remove the final "To dst..." output
> check because there is no output if the process dies with SIGPIPE.
Thanks for a clear write-up.
> This patch accepts the SIGPIPE exit as legitimate test exit.
It is not this patch that accepts such a failure as legit ;-).
"Accept such a death-with-sigpipe also as OK when we are expecting a
failure", perhaps?
> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
> index ec22c98..22a941b 100755
> --- a/t/t5516-fetch-push.sh
> +++ b/t/t5516-fetch-push.sh
> @@ -1162,15 +1162,15 @@ do
> mk_empty shallow &&
> (
> cd shallow &&
> - test_must_fail git fetch ../testrepo/.git $SHA1_3 &&
> - test_must_fail git fetch ../testrepo/.git $SHA1_1 &&
> + test_must_fail_or_sigpipe git fetch ../testrepo/.git $SHA1_3 &&
> + test_must_fail_or_sigpipe git fetch ../testrepo/.git $SHA1_1 &&
> git --git-dir=../testrepo/.git config uploadpack.allowreachablesha1inwant true &&
These I understand.
> git fetch ../testrepo/.git $SHA1_1 &&
> git cat-file commit $SHA1_1 &&
> - test_must_fail git cat-file commit $SHA1_2 &&
> + test_must_fail_or_sigpipe git cat-file commit $SHA1_2 &&
This I don't. Under what condition is it sane for this "cat-file
commit" to fail with sigpipe?
> git fetch ../testrepo/.git $SHA1_2 &&
> git cat-file commit $SHA1_2 &&
> - test_must_fail git fetch ../testrepo/.git $SHA1_3
> + test_must_fail_or_sigpipe git fetch ../testrepo/.git $SHA1_3
And this I do.
> )
> '
> done
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 73e37a1..19a598e 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -600,6 +600,29 @@ test_must_fail () {
> return 0
> }
>
> +# Similar to test_must_fail, but tolerates sigpipe signal, too.
> +
> +test_must_fail_or_sigpipe () {
> + "$@"
> + exit_code=$?
> + if test $exit_code = 0; then
> + echo >&2 "test_must_fail: command succeeded: $*"
> + return 1
> + elif test $exit_code -ne 141 && \
> + test $exit_code -gt 129 && \
> + test $exit_code -le 192; then
> + echo >&2 "test_must_fail: died by signal: $*"
> + return 1
> + elif test $exit_code = 127; then
> + echo >&2 "test_must_fail: command not found: $*"
> + return 1
> + elif test $exit_code = 126; then
> + echo >&2 "test_must_fail: valgrind error: $*"
> + return 1
> + fi
> + return 0
> +}
> +
When you are coming up with this patch, you must have checked the
existing code around this area. Did you notice that 126 is handled
differently between must_fail and might_fail? Can you explain and
justify the difference?
One explanation I can think of is that the contributor who did
eeb69131 (tests: notice valgrind error in test_must_fail,
2013-03-31) did not notice that we do essentially the same thing in
might_fail and forgot to add it. And it is not the fault of that
contributor, but the fault of the duplicated and poorly organized
code back then.
Adding the third variant in the way this patch does is making things
worse by inviting more mistakes.
How about doing something like the attached to consolidate the
existing two into one, and then build this third one on top?
t/test-lib-functions.sh | 41 +++++++++++++++++++++--------------------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index e8d3c0f..54497d6 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -560,22 +560,7 @@ test_line_count () {
# the failure could be due to a segv. We want a controlled failure.
test_must_fail () {
- "$@"
- exit_code=$?
- if test $exit_code = 0; then
- echo >&2 "test_must_fail: command succeeded: $*"
- return 1
- elif test $exit_code -gt 129 && test $exit_code -le 192; then
- echo >&2 "test_must_fail: died by signal: $*"
- return 1
- elif test $exit_code = 127; then
- echo >&2 "test_must_fail: command not found: $*"
- return 1
- elif test $exit_code = 126; then
- echo >&2 "test_must_fail: valgrind error: $*"
- return 1
- fi
- return 0
+ test_failure_helper test_must_fail "$@"
}
# Similar to test_must_fail, but tolerates success, too. This is
@@ -590,13 +575,29 @@ test_must_fail () {
# because we want to notice if it fails due to segv.
test_might_fail () {
+ test_failure_helper test_might_fail "$@"
+}
+
+test_failure_helper () {
+ test_expect=$1
+ shift
"$@"
exit_code=$?
- if test $exit_code -gt 129 && test $exit_code -le 192; then
- echo >&2 "test_might_fail: died by signal: $*"
+ if test $test_expect != test_might_fail && test $exit_code = 0
+ then
+ echo >&2 "$test_expect: command succeeded: $*"
+ return 1
+ elif test $exit_code -gt 129 && test $exit_code -le 192
+ then
+ echo >&2 "$test_expect: died by signal: $*"
+ return 1
+ elif test $exit_code = 127
+ then
+ echo >&2 "$test_expect: command not found: $*"
return 1
- elif test $exit_code = 127; then
- echo >&2 "test_might_fail: command not found: $*"
+ elif test $exit_code = 126
+ then
+ echo >&2 "$test_expect: valgrind error: $*"
return 1
fi
return 0
next prev parent reply other threads:[~2015-11-06 18:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 8:58 [PATCH v4 0/4] Add Travis CI support larsxschneider
2015-11-06 8:58 ` [PATCH v4 1/4] add function test_must_fail_or_sigpipe and use it to fix flaky tests larsxschneider
2015-11-06 18:27 ` Junio C Hamano [this message]
2015-11-06 18:49 ` Junio C Hamano
2015-11-06 8:58 ` [PATCH v4 2/4] git-p4: add p4d timeout in tests larsxschneider
2015-11-06 9:23 ` Eric Sunshine
2015-11-06 13:20 ` Lars Schneider
2015-11-06 8:58 ` [PATCH v4 3/4] git-p4: retry kill/cleanup operations in tests with timeout larsxschneider
2015-11-06 9:28 ` Eric Sunshine
2015-11-06 9:47 ` Lars Schneider
2015-11-06 13:19 ` Lars Schneider
2015-11-06 8:58 ` [PATCH v4 4/4] Add Travis CI support larsxschneider
2015-11-06 9:56 ` Eric Sunshine
2015-11-06 13:18 ` Lars Schneider
[not found] ` <22B2C2B1-9260-4EC0-A4C5-C7F7DDD388BA@gmail.com>
2015-11-06 13:20 ` Sebastian Schuberth
2015-11-06 13:28 ` Lars Schneider
2015-11-06 13:36 ` Sebastian Schuberth
2015-11-06 13:55 ` Lars Schneider
2015-11-06 13:57 ` Sebastian Schuberth
2015-11-06 14:08 ` Lars Schneider
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=xmqqr3k32dc9.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=avila.jn@gmail.com \
--cc=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
--cc=luke@diamand.org \
--cc=sschuberth@gmail.com \
--cc=sunshine@sunshineco.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.