All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Git Mailing List" <git@vger.kernel.org>,
	szeder.dev@gmail.com, "Jan Palus" <jpalus@fastmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: [PATCH] t5570: drop racy test
Date: Thu, 20 Dec 2018 16:41:50 +0000	[thread overview]
Message-ID: <20181220164150.GB25639@hank.intra.tgummerer.com> (raw)
In-Reply-To: <20181126164252.GA27711@sigill.intra.peff.net>

On 11/26, Jeff King wrote:
> On Sun, Nov 25, 2018 at 10:01:38PM +0000, Thomas Gummerer wrote:
> 
> > On 11/25, Torsten Bögershausen wrote:
> > > After running the  "Git 2.20-rc1" testsuite here on a raspi,
> > > the only TC that failed was t5570.
> > > When the "grep" was run on daemon.log, the file was empty (?).
> > > When inspecting it later, it was filled, and grep would have found
> > > the "extended.attribute" it was looking for.
> > 
> > I believe this has been reported before in
> > https://public-inbox.org/git/1522783990.964448.1325338528.0D49CC15@webmail.messagingengine.com/,
> > but it seems like the thread never ended with actually fixing it.
> > Reading the first reply Peff seemed to be fine with just removing the
> > test completely, which would be the easiest solution ;)  Adding him to
> > Cc: here.
> 
> Yes, I don't think there is a way to make this race-proof without
> somehow convincing "cat" to flush (and let us know when it has). Which
> really implies killing the daemon, and wait()ing on cat to process the
> EOF and exit.  And that makes the tests a lot more expensive if we have
> to start the daemon for each snippet.
> 
> So I'm still fine with just dropping this test.

Alright since this has come up twice on the mailing list now (and I've
seen this racyness as well), and nobody found the time to write a
patch yet, below is a patch to just remove the test.

> > > diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
> > > index 7466aad111..e259fee0ed 100755
> > > --- a/t/t5570-git-daemon.sh
> > > +++ b/t/t5570-git-daemon.sh
> > > @@ -192,6 +192,7 @@ test_expect_success 'daemon log records all attributes' '
> > >  	GIT_OVERRIDE_VIRTUAL_HOST=localhost \
> > >  		git -c protocol.version=1 \
> > >  			ls-remote "$GIT_DAEMON_URL/interp.git" &&
> > > +	sleep 1 &&
> > >  	grep -i extended.attribute daemon.log | cut -d" " -f2- >actual &&
> > >  	test_cmp expect actual
> > >  '
> > > ----------------
> > > A slightly better approach may be to use a "sleep on demand":
> > > 
> > > +	( grep -i -q extended.attribute daemon.log || sleep 1 ) &&
> 
> That doesn't really fix it, but just broadens the race window. I dunno.
> Maybe that is enough in practice. We could do something like:
> 
>   repeat_with_timeout () {
> 	local i=0
> 	while test $i -lt 10
> 	do
> 		"$@" && return 0
> 		sleep 1
> 	done
> 	# no success even after 10 seconds
> 	return 1
>   }
> 
>   repeat_with_timeout grep -i extended.attribute daemon.log
> 
> to make the pattern a bit more obvious (and make it easy to extend the
> window arbitrarily; surely 10s is enough?).

I gave this a try, with below patch to lib-git-daemon.sh that you
proposed in the previous thread about this racyness.  That shows
another problem though, namely when truncating 'daemon.log' before
running 'git ls-remote' in this test, we're not sure all 'git deamon'
has flushed everything from previous invocations.  That may be an even
rarer problem in practice, but still something to keep in mind.

diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index edbea2d986..3c7fea169b 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -62,6 +62,7 @@ start_git_daemon() {
 		(
 			while read -r line <&7
 			do
+				sleep 1
 				printf "%s\n" "$line"
 				printf >&4 "%s\n" "$line"
 			done

Dscho also mentioned on #git-devel a while ago that he may have a look
at actually making this test race-proof, but I guess he's been busy
with the 2.20 release.  I'm also not sure it's worth spending a lot of
time trying to fix this test, but I'd definitely be happy if someone
proposes a different solution.

> -Peff

--- >8 ---
Subject: [PATCH] t5570: drop racy test

t5570 being racy has been reported twice separately on the mailing
list [*1*, *2*].

To make the test race proof, we'd either have to introduce another
fifo the test snippet is waiting on, or somehow convincing "cat" to
flush (and let us know when it has).  Which really implies killing the
daemon, and wait()ing on cat to process the EOF and exit.  And that
makes the tests a lot more expensive if we have to start the daemon
for each snippet.

As this is a test for a relatively minor fix (according to the author)
in 19136be3f8 ("daemon: fix off-by-one in logging extended
attributes", 2018-01-24), drop it to avoid this racyness.  It doesn't
seem worth making the test code much more complex, or slowing down all
tests just to keep this one.

*1*: 1522783990.964448.1325338528.0D49CC15@webmail.messagingengine.com/
*2*: 9d4e5224-9ff4-f3f8-519d-7b2a6f1ea7cd@web.de

Reported-by: Jan Palus <jpalus@fastmail.com>
Reported-by: Torsten Bögershausen <tboegi@web.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 t/t5570-git-daemon.sh | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
index 7466aad111..58ee787685 100755
--- a/t/t5570-git-daemon.sh
+++ b/t/t5570-git-daemon.sh
@@ -183,19 +183,6 @@ test_expect_success 'hostname cannot break out of directory' '
 		git ls-remote "$GIT_DAEMON_URL/escape.git"
 '
 
-test_expect_success 'daemon log records all attributes' '
-	cat >expect <<-\EOF &&
-	Extended attribute "host": localhost
-	Extended attribute "protocol": version=1
-	EOF
-	>daemon.log &&
-	GIT_OVERRIDE_VIRTUAL_HOST=localhost \
-		git -c protocol.version=1 \
-			ls-remote "$GIT_DAEMON_URL/interp.git" &&
-	grep -i extended.attribute daemon.log | cut -d" " -f2- >actual &&
-	test_cmp expect actual
-'
-
 test_expect_success FAKENC 'hostname interpolation works after LF-stripping' '
 	{
 		printf "git-upload-pack /interp.git\n\0host=localhost" | packetize
-- 
2.20.1.415.g653613c723


  reply	other threads:[~2018-12-20 16:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 20:52 t5570 shaky for anyone ? Torsten Bögershausen
2018-11-25 22:01 ` Thomas Gummerer
2018-11-26 16:42   ` Jeff King
2018-12-20 16:41     ` Thomas Gummerer [this message]
2018-12-20 17:14       ` [PATCH] t5570: drop racy test Jeff King
2018-12-21 15:48         ` Johannes Schindelin
2019-01-06 17:59           ` Thomas Gummerer
2019-01-06 17:53       ` [PATCH 2/1] Revert "t/lib-git-daemon: record daemon log" Thomas Gummerer
2019-01-07  8:20         ` Jeff King
2019-01-07 15:45           ` Junio C Hamano
2018-11-25 22:22 ` t5570 shaky for anyone ? SZEDER Gábor
2018-11-26 16:45   ` Jeff King

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=20181220164150.GB25639@hank.intra.tgummerer.com \
    --to=t.gummerer@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jpalus@fastmail.com \
    --cc=peff@peff.net \
    --cc=szeder.dev@gmail.com \
    --cc=tboegi@web.de \
    /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.