Re: t1450-fsck (sometimes/often) failes on Mac OS X

From: Jeff King <peff@peff.net>
Date: Jul 15, 2012, 09:08 UTC
Message-ID: <20120715090849.GB18385@sigill.intra.peff.net>
In-Reply-To: <5001644F.10901@web.de>

On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:

Show 7 quoted lines

> I saw the problem first on pu, some time ago, 
> but it dissappeared after cloning git.git into another directory.
> 
> Now it appeared on next as well, so it's time to look a little bit deeper.
> 
> This test case of t1450 fails:
> test_expect_success 'tag pointing to something else than its type' '

I can't reproduce this failure; I tried both pu or next, on Linux and OS X (10.7).

Show 8 quoted lines

> Linux:
> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
> 
> Mac OS X:
> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing

That seems very broken. That sha1 can have only one type, so OS X is actually mis-parsing the object type? Weird. I would suggest a memory error or race condition, but the test is valgrind-clean, and fsck should not be threaded at all.

What does "git show 63499e4" show when the test has failed? If you re-run "git fsck --tags", does it reproduce reliably (i.e., is it bogus data that something wrote to the object db, or is it good data being ruined during the reading process)?

Show 6 quoted lines

> I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help
> 
> Looking into the trash directory and looking at the files, we can see that the .git/index is different
> between Linux and Mac OS X.
> 
> Is there a good way to debug the index file?

git ls-files -s will dump the entries. But I'd expect them not to be byte-equivalent, because the index will contain things like mtimes for each entry, which will vary from run to run. Plus the error message above indicates something much more broken.

-Peff