Re: Intermittent Failures in t1450-fsck (Bisected)

[Jeff King <peff@peff.net>]

On Thu, May 05, 2011 at 02:46:52AM -0400, Brian Gernhardt wrote:

> I finally managed to pin down what triggers the bug and bisect it to
> its beginning.
> 
> I see this failure only when the test suite is run in parallel.  (make
> -j or -j in GIT_PROVE_OPTS)
> 
> The bug starts happening in "e96c19c: config: support values longer than 1023 bytes".

I'm slightly confused. Commit e96c19c predates the test that you
reported as failing here:

> > t1450-fsck fails in test 10 "tag pointing to something else than its type", but only if I run it as part of the full test suite (with either `make test` or `make prove`).  If I run the test separately, it passes.
> > 
> > The output from running with GIT_TEST_OPTS="-v" is:
> > 
> > expecting success: 
> > 	sha=$(echo blob | git hash-object -w --stdin) &&
> > 	test_when_finished "remove_object $sha" &&
> > 	cat >wrong-tag <<-EOF &&
> > 	object $sha
> > 	type commit
> > 	tag wrong
> > 	tagger T A Gger <tagger@example.com> 1234567890 -0000
> > 
> > 	This is an invalid tag.
> > 	EOF
> > 
> > 	tag=$(git hash-object -t tag -w --stdin <wrong-tag) &&
> > 	test_when_finished "remove_object $tag" &&
> > 	echo $tag >.git/refs/tags/wrong &&
> > 	test_when_finished "git update-ref -d refs/tags/wrong" &&
> > 	test_must_fail git fsck --tags 2>out &&
> > 	cat out &&
> > 	grep "error in tag.*broken links" out
> > 
> > tagged commit 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 (wrong) in 66f6581d549f70e05ca586bc2df5c15a95662c36
> > missing commit 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
> > error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
> > error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
> > not ok - 10 tag pointing to something else than its type

So how did you bisect down to it? You said reverting e96c19c fixes it,
which does seem like strong evidence, but what I am wondering is if a
_different_ test in t1450 fails at e96c19c. That would point to
something else funny going on.

Double weird is that my output for t1450.10 is totally different from
that.  Which commit are you testing on?

Given that the problem seems racy and intermittent, have you tried
running under valgrind?

-Peff