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

[Jeff King <peff@peff.net>]

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

> 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).

> 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)?

> 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