Re: Intermittent Failures in t1450-fsck (Bisected)

[Jeff King <peff@peff.net>]

On Sat, May 07, 2011 at 04:25:28PM -0400, Brian Gernhardt wrote:

> I've tried to narrow it down even further.  I cut the test down to
> just the setup and failing test. Then I removed all
> "test_when_finished" and replaced the "test_must_fail" with "!" so I
> can directly copy/paste the test into a window.  When the test runs,
> it fails.  When I run it manually, even with using /bin/sh and eval,
> it succeeds.  Can anybody else think of what difference there might be
> between a shell and the test script that I should test?  (I did
> remember to set GIT_EXEC_PATH and my PATH to run the same version as
> the script is.)

Could be something in the environment. You might want to try pulling the
environment variable setup from test-lib.sh into your interactive shell.

I would suspect earlier tests might have created some weird state, but
it looks in your output like you removed most of them and still see the
problem.

> expecting success: 
> 	sha=$(echo blob | git hash-object -w --stdin) &&
> 	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) &&
> 	echo $tag >.git/refs/tags/wrong &&
> 	! 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 - 3 tag pointing to something else than its type

Thanks for narrowing it down more. One thing I'd try is to see what "git
cat-file -t $sha" and "git cat-file -p $sha" say right before the fsck
is run (they should both print "blob").

Beyond that I think I'd try gdb, with breakpoints near the places those
messages are generated (you can find them by grepping for "tagged %s %s"
and "is a %s, not a").

Other than that, I'm a bit stumped. The whole "it breaks on a ramdisk"
thing is just odd.

-Peff