{"thread":{"id":"31023","subject":"t1450-fsck (sometimes/often) failes on Mac OS X","startedAt":"2012-07-14T12:21:35Z","lastAt":"2012-10-03T19:37:51Z","messageCount":14,"participants":["Torsten Bögershausen","Jeff King","Thomas Rast","Heiko Voigt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"195043","messageId":"5001644F.10901@web.de","threadId":"31023","inReplyTo":null,"subject":"t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-07-14T12:21:35Z","receivedAt":"2012-07-14T12:21:35Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"I saw the problem first on pu, some time ago, \nbut it dissappeared after cloning git.git into another directory.\n\nNow it appeared on next as well, so it's time to look a little bit deeper.\n\nThis test case of t1450 fails:\ntest_expect_success 'tag pointing to something else than its type' '\n\nTo debug more, I added an exit 0 here to inspect the file named out:\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nindex 5b79c51..f1f45c9 100755\n--- a/t/t1450-fsck.sh\n+++ b/t/t1450-fsck.sh\n@@ -179,6 +179,7 @@ test_expect_success 'tag pointing to something else than its type' '\n test_when_finished \"git update-ref -d refs/tags/wrong\" &&\n test_must_fail git fsck --tags 2>out &&\n cat out &&\n+ exit 0\n grep \"error in tag.*broken links\" out\n '\n\nLinux:\nerror: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\nerror in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\nerror in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n\nMac OS X:\nerror: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\nerror: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n\nI reverted the last change in fsck.c (Use the streaming interface), but that doesn't help\n\nLooking into the trash directory and looking at the files, we can see that the .git/index is different\nbetween Linux and Mac OS X.\n\nIs there a good way to debug the index file?\n\nBTW: git bisect pointed out: \n [76759c7dff53e8c84e975b88cb8245587c14c7ba] git on Mac OS and precomposed unicode\nBut re-running t1450 makes it pass, so that bisect went into the wrong direction\nsomewhere.\n\nIt seems that t1450 is timing depending, sometimes it passes, sometimes not.\nAnd once it went into the state \"non passed\", it stays there.\n\nIt feels that I got stuck, any hints how to debug this further, please ?\n\n/Torsten\n"},{"id":"195078","messageId":"20120715090849.GB18385@sigill.intra.peff.net","threadId":"31023","inReplyTo":"5001644F.10901@web.de","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-07-15T09:08:50Z","receivedAt":"2012-07-15T09:08:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:\n\n> I saw the problem first on pu, some time ago, \n> but it dissappeared after cloning git.git into another directory.\n> \n> Now it appeared on next as well, so it's time to look a little bit deeper.\n> \n> This test case of t1450 fails:\n> test_expect_success 'tag pointing to something else than its type' '\n\nI can't reproduce this failure; I tried both pu or next, on Linux and OS\nX (10.7).\n\n> Linux:\n> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n> \n> Mac OS X:\n> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n\nThat seems very broken. That sha1 can have only one type, so OS X is\nactually mis-parsing the object type? Weird. I would suggest a memory\nerror or race condition, but the test is valgrind-clean, and fsck should\nnot be threaded at all.\n\nWhat does \"git show 63499e4\" show when the test has failed? If you\nre-run \"git fsck --tags\", does it reproduce reliably (i.e., is it bogus\ndata that something wrote to the object db, or is it good data being\nruined during the reading process)?\n\n> I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help\n> \n> Looking into the trash directory and looking at the files, we can see that the .git/index is different\n> between Linux and Mac OS X.\n> \n> Is there a good way to debug the index file?\n\ngit ls-files -s will dump the entries. But I'd expect them not to be\nbyte-equivalent, because the index will contain things like mtimes for\neach entry, which will vary from run to run. Plus the error message\nabove indicates something much more broken.\n\n-Peff\n"},{"id":"195081","messageId":"5002BF88.4090002@web.de","threadId":"31023","inReplyTo":"20120715090849.GB18385@sigill.intra.peff.net","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-07-15T13:03:04Z","receivedAt":"2012-07-15T13:03:04Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"Peff, thanks for looking into this.\n\nMy answers are inline and at the end.\n\nOn 15.07.12 11:08, Jeff King wrote:\n> On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:\n> \n>> I saw the problem first on pu, some time ago, \n>> but it dissappeared after cloning git.git into another directory.\n>>\n>> Now it appeared on next as well, so it's time to look a little bit deeper.\n>>\n>> This test case of t1450 fails:\n>> test_expect_success 'tag pointing to something else than its type' '\n> \n> I can't reproduce this failure; I tried both pu or next, on Linux and OS\n> X (10.7).\n> \n>> Linux:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>>\n>> Mac OS X:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n> \n> That seems very broken. That sha1 can have only one type, so OS X is\n> actually mis-parsing the object type? Weird. I would suggest a memory\n> error or race condition, but the test is valgrind-clean, and fsck should\n> not be threaded at all.\n> \n> What does \"git show 63499e4\" show when the test has failed? \n ../../git show 63499e4\nblob\n\n\n> If you re-run \"git fsck --tags\", does it reproduce reliably (i.e., is it bogus\n> data that something wrote to the object db, or is it good data being\n> ruined during the reading process)?\n\n ../../git fsck --tags\nChecking object directories: 100% (256/256), done.\nerror: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\nerror in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\nerror in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\nbroken link from tag 66f6581d549f70e05ca586bc2df5c15a95662c36\nbroken link from unknown unknown\ndangling blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\n\n> \n>> I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help\n>>\n>> Looking into the trash directory and looking at the files, we can see that the .git/index is different\n>> between Linux and Mac OS X.\n>>\n>> Is there a good way to debug the index file?\n> \n> git ls-files -s will dump the entries. But I'd expect them not to be\n> byte-equivalent, because the index will contain things like mtimes for\n> each entry, which will vary from run to run. Plus the error message\n> above indicates something much more broken.\n ../../git ls-files -s\n100644 5626abf0f72e58d7a153368ba57db4c673c0e171 0 fileA\n100644 f719efd430d52bcfc8566a43b2eb655688d38871 0 fileB\n\n\nI did some bisecting, and it didn't lead to a bad commit.\nThe problem goes away after another clone into a fresh directory.\n\nOnce it comes up, it seems to stay within that working tree.\nOr it has something to do with the uptime of the machine (?)\n\nChecking out v1.7.10 seems to make the problem go away, and\nstepping up to e.g.\n>commit d30ef5144cee3e9ed01a2a3f3b96d47c5322b20d\n> Merge branch 'jc/sha1-name-more' into next\n\nbrings the failure back.\n\nThis is probably not related to this very 2 commits, so may be a\n\"reverse bisect\" would help, (\"When does the problem go away?\")\n\nThanks for helping\n\n/Torsten\n\n\n\n\n\n\n\n\n\n\n\n\n> \n> -Peff\n"},{"id":"195097","messageId":"87y5mkm935.fsf@thomas.inf.ethz.ch","threadId":"31023","inReplyTo":"5001644F.10901@web.de","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-07-16T07:57:50Z","receivedAt":"2012-07-16T07:57:50Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Torsten Bögershausen writes:\n\n> Now it appeared on next as well, so it's time to look a little bit deeper.\n>\n> This test case of t1450 fails:\n> test_expect_success 'tag pointing to something else than its type' '\n>\n> To debug more, I added an exit 0 here to inspect the file named out:\n> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\n> index 5b79c51..f1f45c9 100755\n> --- a/t/t1450-fsck.sh\n> +++ b/t/t1450-fsck.sh\n> @@ -179,6 +179,7 @@ test_expect_success 'tag pointing to something else than its type' '\n> test_when_finished \"git update-ref -d refs/tags/wrong\" &&\n> test_must_fail git fsck --tags 2>out &&\n> cat out &&\n> + exit 0\n> grep \"error in tag.*broken links\" out\n> '\n>\n> Linux:\n> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>\n> Mac OS X:\n> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n\nWhat OS X are you running? I started a loop\n\n while : ; do ./t1450-fsck.sh || break; done\n\nand it hasn't failed yet. It is\n\n $ uname -a\n Darwin mackeller.inf.ethz.ch 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64\n\n> I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help\n>\n> Looking into the trash directory and looking at the files, we can see that the .git/index is different\n> between Linux and Mac OS X.\n>\n> Is there a good way to debug the index file?\n\nYou can run 'git ls-files --debug' which should give you all the data in\nthe index, and then perhaps run diff over that to determine the\ndifferences...\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"195124","messageId":"899A52DB-E548-44CD-8624-A715DDB17032@web.de","threadId":"31023","inReplyTo":"87y5mkm935.fsf@thomas.inf.ethz.ch","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-07-16T16:06:26Z","receivedAt":"2012-07-16T16:06:26Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\nAm 16.07.2012 um 09:57 schrieb Thomas Rast:\n\n> Torsten Bögershausen writes:\n> \n>> Now it appeared on next as well, so it's time to look a little bit deeper.\n>> \n>> This test case of t1450 fails:\n>> test_expect_success 'tag pointing to something else than its type' '\n>> \n>> To debug more, I added an exit 0 here to inspect the file named out:\n>> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\n>> index 5b79c51..f1f45c9 100755\n>> --- a/t/t1450-fsck.sh\n>> +++ b/t/t1450-fsck.sh\n>> @@ -179,6 +179,7 @@ test_expect_success 'tag pointing to something else than its type' '\n>> test_when_finished \"git update-ref -d refs/tags/wrong\" &&\n>> test_must_fail git fsck --tags 2>out &&\n>> cat out &&\n>> + exit 0\n>> grep \"error in tag.*broken links\" out\n>> '\n>> \n>> Linux:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>> \n>> Mac OS X:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n> \n> What OS X are you running? I started a loop\n> \n> while : ; do ./t1450-fsck.sh || break; done\n> \n> and it hasn't failed yet. It is\n> \n> $ uname -a\n> Darwin mackeller.inf.ethz.ch 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64\n> \n uname -a\nDarwin birne.lan 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386\n> \n> You can run 'git ls-files --debug' which should give you all the data in\n> the index, and then perhaps run diff over that to determine the\n> differences...\n> \n\nThat lloks like this:\n\nfileA\n ctime: 1342453768:0\n mtime: 1342453768:0\n dev: 234881026 ino: 92698027\n uid: 1500 gid: 20\n size: 4 flags: 5\nfileB\n ctime: 1342453768:0\n mtime: 1342453768:0\n dev: 234881026 ino: 92698053\n uid: 1500 gid: 20\n size: 4 flags: 5\n\n==================\nBut what is interesting, is that \na) When I clone a fresh copy from git.git, it works OK. After some activity with the working dir,\n suddenly t1450 fails. Switching back to e.g. v1.7.11 makes t1450 pass again.\n Switching to origin/next , running make brings back the problem, t1450 fails\n\nb) The failure seems to be time critical. When I run the test yesterday evening,\n being logged in via ssh makes the test pass.\n Sitting at the machine makes it fail.\n\nc) It seems as if there is a problem when writing to disk.\n Could be the index file\n (git ls-files --debug does not dump the whole index, does it?)\n\nd) As Peff pointed out, the fsck itself is not time critical.\n \nThanks for looking into it\n"},{"id":"196031","messageId":"20120728154320.GA98893@book.hvoigt.net","threadId":"31023","inReplyTo":"899A52DB-E548-44CD-8624-A715DDB17032@web.de","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-07-28T15:43:23Z","receivedAt":"2012-07-28T15:43:23Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\njust to verify that this is unlikely just a hardware issue on one machine. I\ntoday experienced this failure on master as well.\n\nOn Mon, Jul 16, 2012 at 06:06:26PM +0200, Torsten B?gershausen wrote:\n> \n> Am 16.07.2012 um 09:57 schrieb Thomas Rast:\n> \n> > Torsten Bögershausen writes:\n> > What OS X are you running? I started a loop\n> > \n> > while : ; do ./t1450-fsck.sh || break; done\n> > \n> > and it hasn't failed yet. It is\n> > \n> > $ uname -a\n> > Darwin mackeller.inf.ethz.ch 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64\n> > \n> uname -a\n> Darwin birne.lan 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386\n\n$ uname -a\nDarwin book.hvoigt.net 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386\n\nMy bisect run did also not reveal anything useful. I tried to use valgrind.\nInterestingly just by prepending my valgrind directory to the PATH the test\npasses. When changing PATH further it sometimes passes and sometimes not.\nReopening a new shell it reliably fails.\n\nThe commit I am experiencing this with is cdd159b. This one reliably fails for\nme with the correct path setting :-)\n\nTo me this smells a little bit like using a dangling pointer or uninitialized\nmemory since threading seems to be out of the game. A dangling pointer only\navailable on a certain OS X version?\n\nIf I modify the PATH after adding the valgrind bin folder so that it matches\nthe same amount of characters as before I get the failure again.\n\nIt seems the error only occurs if my PATH is exactly 280 characters long. E.g.:\n\nexport PATH=/usr/local/valgrind/bin:/Users/hvoigt/.local/bin:/usr/bin:/bin:/usr/local/bin:/sw/bin/:/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n\nWhen running under valgrind test 13 (the original one) passes but 2 fails. Not\nsure if this is a false positive[1].\n\nIf I add those eight bytes here the tests pass for me without valgrind:\n\ndiff --git a/environment.c b/environment.c\nindex 85edd7f..988f836 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -131,7 +131,7 @@ static void setup_git_env(void)\n }\n git_index_file = getenv(INDEX_ENVIRONMENT);\n if (!git_index_file) {\n- git_index_file = xmalloc(strlen(git_dir) + 7);\n+ git_index_file = xmalloc(strlen(git_dir) + 7 + 8);\n sprintf(git_index_file, \"%s/index\", git_dir);\n }\n git_graft_file = getenv(GRAFT_ENVIRONMENT);\n\nBut maybe thats just a coincidence and totally unrelated.\n\nThe valgrind error can be fixed by this change:\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 4ccaf7a..631d0dd 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -251,7 +251,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative\n const char *objdir = get_object_directory();\n struct alternate_object_database *ent;\n struct alternate_object_database *alt;\n- int pfxlen, entlen;\n+ int pfxlen, entlen, objdirlen;\n struct strbuf pathbuf = STRBUF_INIT;\n \n if (!is_absolute_path(entry) && relative_base) {\n@@ -298,7 +298,8 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative\n return -1;\n }\n }\n- if (!memcmp(ent->base, objdir, pfxlen)) {\n+ objdirlen = strlen(objdir);\n+ if (!memcmp(ent->base, objdir, pfxlen > objdirlen ? objdirlen : pfxlen)) {\n free(ent);\n return -1;\n }\n\nI will format this into a proper patch independent from this mail.\n\nThese are my observations.\n\nCheers Heiko\n\n[1]\n$ ./t1450-fsck.sh --valgrind\n[...]\nexpecting success: \n\tmkdir another &&\n\t(\n\t\tcd another &&\n\t\tgit init &&\n\t\techo ../../../.git/objects >.git/objects/info/alternates &&\n\t\ttest_commit C fileC one &&\n\t\tgit fsck --no-dangling >../actual 2>&1\n\t) &&\n\ttest_cmp empty actual\n\nInitialized empty Git repository in /Users/hvoigt/Repository/git/t/trash directory.t1450-fsck/another/.git/\n==42686== Invalid read of size 8\n==42686== at 0x100625064: bcmp (in /usr/lib/libSystem.B.dylib)\n==42686== by 0x100112846: link_alt_odb_entries (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1001129C0: read_info_alternates (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100112B8C: prepare_alt_odb (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1001148B7: prepare_packed_git (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100116A8B: find_pack_entry (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100118008: has_sha1_file (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100117DFA: write_sha1_file (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100118268: index_mem (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1001183DC: index_core (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100118586: index_fd (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1001186DA: index_path (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== Address 0x100faca78 is 8 bytes inside a block of size 13 alloc'd\n==42686== at 0x10029C679: malloc (vg_replace_malloc.c:266)\n==42686== by 0x1001349CD: xmalloc (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1000C23F5: setup_git_env (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1000C286B: set_git_dir (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x100110128: setup_work_tree (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1000022F2: run_builtin (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1000024DA: handle_internal_command (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x1000025E8: run_argv (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== by 0x10000275F: main (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n==42686== \n{\n \n Memcheck:Addr8\n fun:bcmp\n fun:link_alt_odb_entries\n fun:read_info_alternates\n fun:prepare_alt_odb\n fun:prepare_packed_git\n fun:find_pack_entry\n fun:has_sha1_file\n fun:write_sha1_file\n fun:index_mem\n fun:index_core\n fun:index_fd\n fun:index_path\n}\nnot ok - 2 loose objects borrowed from alternate are not missing\n"},{"id":"196033","messageId":"87hasrdgej.fsf@thomas.inf.ethz.ch","threadId":"31023","inReplyTo":"20120728154320.GA98893@book.hvoigt.net","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-07-28T16:00:52Z","receivedAt":"2012-07-28T16:00:52Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Heiko Voigt writes:\n\n> if (!git_index_file) {\n> - git_index_file = xmalloc(strlen(git_dir) + 7);\n> + git_index_file = xmalloc(strlen(git_dir) + 7 + 8);\n> sprintf(git_index_file, \"%s/index\", git_dir);\n> }\n[...]\n> - if (!memcmp(ent->base, objdir, pfxlen)) {\n> + objdirlen = strlen(objdir);\n> + if (!memcmp(ent->base, objdir, pfxlen > objdirlen ? objdirlen : pfxlen)) {\n[...]\n> Initialized empty Git repository in /Users/hvoigt/Repository/git/t/trash directory.t1450-fsck/another/.git/\n> ==42686== Invalid read of size 8\n> ==42686== at 0x100625064: bcmp (in /usr/lib/libSystem.B.dylib)\n> ==42686== by 0x100112846: link_alt_odb_entries (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n> ==42686== by 0x1001129C0: read_info_alternates (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n[...]\n> ==42686== Address 0x100faca78 is 8 bytes inside a block of size 13 alloc'd\n> ==42686== at 0x10029C679: malloc (vg_replace_malloc.c:266)\n> ==42686== by 0x1001349CD: xmalloc (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n> ==42686== by 0x1000C23F5: setup_git_env (in /Users/hvoigt/Repository/git/t/valgrind/../../git)\n\nTo me that looks just like a false positive. memcmp (which seems to be\nthe same as bcmp) can load 8 bytes from an aligned address even if these\nare only partially within the block being compared, since an aligned\nload can never partially fault (it must all be within the same page).\nValgrind normally substitutes its own routines for memcmp etc. to\ncorrectly handle this, but this does not seem to happen in your case for\nsome reason.\n\nThen again I am not entirely sure how you could verify that this theory\nis correct :-)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"199480","messageId":"5059ED25.9090002@web.de","threadId":"31023","inReplyTo":"20120715090849.GB18385@sigill.intra.peff.net","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-09-19T16:04:53Z","receivedAt":"2012-09-19T16:04:53Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 07/15/2012 11:08 AM, Jeff King wrote:\n> On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:\n>\n>> I saw the problem first on pu, some time ago,\n>> but it dissappeared after cloning git.git into another directory.\n>>\n>> Now it appeared on next as well, so it's time to look a little bit deeper.\n>>\n>> This test case of t1450 fails:\n>> test_expect_success 'tag pointing to something else than its type' '\n>\n> I can't reproduce this failure; I tried both pu or next, on Linux and OS\n> X (10.7).\n>\n>> Linux:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>>\n>> Mac OS X:\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n>\n> That seems very broken. That sha1 can have only one type, so OS X is\n> actually mis-parsing the object type? Weird. I would suggest a memory\n> error or race condition, but the test is valgrind-clean, and fsck should\n> not be threaded at all.\n>\n> What does \"git show 63499e4\" show when the test has failed? If you\n> re-run \"git fsck --tags\", does it reproduce reliably (i.e., is it bogus\n> data that something wrote to the object db, or is it good data being\n> ruined during the reading process)?\n>\n>> I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help\n>>\n>> Looking into the trash directory and looking at the files, we can see that the .git/index is different\n>> between Linux and Mac OS X.\n>>\n>> Is there a good way to debug the index file?\n>\n> git ls-files -s will dump the entries. But I'd expect them not to be\n> byte-equivalent, because the index will contain things like mtimes for\n> each entry, which will vary from run to run. Plus the error message\n> above indicates something much more broken.\n>\nAfter some time, the problem is still there\n\nWhen I make a fresh clone of git.git under Mac OS, 1450 passes.\nAfter a while, running things like \"git fetch && git checkout \norigin/next && make clean && make test\", it starts to fail.\n\n(currently I have a couple of git repo-copies, t1450 fails in git.pu \nand passes in git.next.\nBut that has nothing to do with next or pu)\n\nWhen I run ssh into the Mac OS X machine, the test case passes even in pu.\nVery strange, but reproducable.\n\nNow things become more puzzled:\nI managed to re-produce it on a Linux machine as well.\nUsing v1.7.12 and applying my i18.pathencoding patch,\nt1450 fails on Linux, regardless if I use ssh or sit locally at the machine.\n\nI make a new version of t1450-fsck.sh, called t1450-fsck2.sh\nThat uses git fsck --verbose, I add the log file here.\nThe short version:\n- I can re-run the \"git fsck\", all files on disk have the same md5.\n- The 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 has the same md5 as well\nI added lots of printouts in git code, according to my understanding \n63499 is checked/fsck'ed after being loaded into RAM, is that right?\n\nFor some reasons it is classified as \"is a blob, not a commit\" when it \npasses and \"is a commit, not a blob\" when it fails.\n\nI want to debug when it is loaded into RAM, so that code is in \nread-cache.c, isn't it?\n\nDoes anybody have a tool to debug the contents of the index file?\nEven offline could help, I can send a bunch of files ;-)\n\nAnd why doesn't fsck find the broken link?\n\nOther ideas are welcome,\nthanks everybody for reading/helping.\n/Torsten\n\n\"out\" after running git fsck --verbose --tags, t1450 failed\n(no broken link)\n============\nChecking HEAD link\nChecking object directory\nChecking directory .git/objects/13\nChecking directory .git/objects/15\nChecking directory .git/objects/1b\nChecking directory .git/objects/30\nChecking directory .git/objects/35\nChecking directory .git/objects/44\nChecking directory .git/objects/56\nChecking directory .git/objects/63\nChecking directory .git/objects/66\nChecking directory .git/objects/af\nChecking directory .git/objects/b6\nChecking directory .git/objects/bd\nChecking directory .git/objects/c4\nChecking directory .git/objects/c9\nChecking directory .git/objects/f7\nChecking tag 66f6581d549f70e05ca586bc2df5c15a95662c36\nChecking commit 134756353796a5439d93586be27999eea3807a34\nChecking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\nerror: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not \na blob\nerror: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\nChecking tree bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7\nChecking commit c9145d6720f85544cc4bb6009a2e541660aa156b\nChecking tree c9176b0dd1a95c80ad8de21784b1eeffd3681f49\nChecking blob f719efd430d52bcfc8566a43b2eb655688d38871\nChecking cache tree\nChecking connectivity (32 objects)\nChecking 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\nChecking 66f6581d549f70e05ca586bc2df5c15a95662c36\nChecking c9145d6720f85544cc4bb6009a2e541660aa156b\nChecking c9176b0dd1a95c80ad8de21784b1eeffd3681f49\nChecking 134756353796a5439d93586be27999eea3807a34\nChecking 5626abf0f72e58d7a153368ba57db4c673c0e171\nChecking f719efd430d52bcfc8566a43b2eb655688d38871\nChecking bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7\n===========\n\n\ndiff failed passed\ndiff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out\n17a18,20\n > Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n > Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\n > error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not \na commit\n18a22,23\n > error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n > error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load \ntagged object\n20,22d24\n< Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n< error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, \nnot a blob\n< error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n"},{"id":"199508","messageId":"7va9wlhnl3.fsf@alter.siamese.dyndns.org","threadId":"31023","inReplyTo":"5059ED25.9090002@web.de","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-19T18:30:48Z","receivedAt":"2012-09-19T18:30:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n>>> Linux:\n>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>>>\n>>> Mac OS X:\n>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n\nInteresting difference.\n\n>> That seems very broken. That sha1 can have only one type, so OS X is\n>> actually mis-parsing the object type? Weird. I would suggest a memory\n>> error or race condition, but the test is valgrind-clean, and fsck should\n>> not be threaded at all.\n\n\"is a blob, not a commit\" is likely to come from validating of the\ntag 66f6581d that presumably point at 63499e4; it reads the tag,\nlearns the name of the object that is tagged and the type of it,\nremembers that the object pointed at (which it hasn't and is going\nto validate next) _must_ be a commit (because tag says so) and then\nrealizes when it reads 63499e4 it is a blob and barfs.\n\nAnd that is what _should_ happen in that test. It crafts a\nmalformed tag that points at a blob and claims that it is a commit.\nThe test makes sure fsck catches that, and it does.\n\nOn the other hand, \"is a commit, not a blob\", unless you have a tag\nthat directly points at a blob, is more likely to come from\nvalidating some tree object. It reads the tree, learns the name of\nthe object contained in the tree and infers the type of that object\nfrom the mode bits in the tree (100644 or 100755 would mean the\nobject must be a blob), goes on to validate that object and realizes\nit is a commit and barfs.\n\nIt is veriy unusual to get, even on two different platforms, both\nmessages for the same object.\n\nCould it be that you have i18n on \"Object %s is a %s, not a %s\" with\na wrong .po file that swaps the latter two parameters in the output?\n\n>> What does \"git show 63499e4\" show when the test has failed?\n\nWas this question ever answered (I would prever \"cat-file -t\"\nfollowed by \"cat-file \" instead of \"show\" for things like\nthis)? It should show that it is a blob whose contents is \"blob\\n\".\n\n> Checking tag 66f6581d549f70e05ca586bc2df5c15a95662c36\n> Checking commit 134756353796a5439d93586be27999eea3807a34\n> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit,\n> not a blob\n> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n> Checking tree bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7\n> Checking commit c9145d6720f85544cc4bb6009a2e541660aa156b\n> Checking tree c9176b0dd1a95c80ad8de21784b1eeffd3681f49\n> Checking blob f719efd430d52bcfc8566a43b2eb655688d38871\n> Checking cache tree\n> Checking connectivity (32 objects)\n> Checking 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\n> Checking 66f6581d549f70e05ca586bc2df5c15a95662c36\n> Checking c9145d6720f85544cc4bb6009a2e541660aa156b\n> Checking c9176b0dd1a95c80ad8de21784b1eeffd3681f49\n> Checking 134756353796a5439d93586be27999eea3807a34\n> Checking 5626abf0f72e58d7a153368ba57db4c673c0e171\n> Checking f719efd430d52bcfc8566a43b2eb655688d38871\n> Checking bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7\n> ===========\n>\n>\n> diff failed passed\n> diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out\n> 17a18,20\n>> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n>> Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\n>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n\nThis is the correct behaviour.\n\n> 18a22,23\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n\nThis too.\n\n> 20,22d24\n> < Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n> < error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n> < error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n"},{"id":"199530","messageId":"505A29DF.6030501@web.de","threadId":"31023","inReplyTo":"7va9wlhnl3.fsf@alter.siamese.dyndns.org","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-09-19T20:23:59Z","receivedAt":"2012-09-19T20:23:59Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"Thanks Junio,\nand all readers\ncommenst and answers are inline\n\nOn 19.09.12 20:30, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n> \n>>>> Linux:\n>>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n>>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n>>>>\n>>>> Mac OS X:\n>>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>>>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n> \n> Interesting difference.\n> \n>>> That seems very broken. That sha1 can have only one type, so OS X is\n>>> actually mis-parsing the object type? Weird. I would suggest a memory\n>>> error or race condition, but the test is valgrind-clean, and fsck should\n>>> not be threaded at all.\n> \n> \"is a blob, not a commit\" is likely to come from validating of the\n> tag 66f6581d that presumably point at 63499e4; it reads the tag,\n> learns the name of the object that is tagged and the type of it,\n> remembers that the object pointed at (which it hasn't and is going\n> to validate next) _must_ be a commit (because tag says so) and then\n> realizes when it reads 63499e4 it is a blob and barfs.\n> \n> And that is what _should_ happen in that test. It crafts a\n> malformed tag that points at a blob and claims that it is a commit.\n> The test makes sure fsck catches that, and it does.\n> \n> On the other hand, \"is a commit, not a blob\", unless you have a tag\n> that directly points at a blob, is more likely to come from\n> validating some tree object. It reads the tree, learns the name of\n> the object contained in the tree and infers the type of that object\n> from the mode bits in the tree (100644 or 100755 would mean the\n> object must be a blob), goes on to validate that object and realizes\n> it is a commit and barfs.\nSorry for not knowing better and asking stupid questions.\n\"Reads the tree\", does it mean \"read the index file\" and put all objects into memory\nor does it mean \"scan the file system using readdir()\"\nOr is both done?\n\nIt looks as if there is a different execution order (wild speculation)\n\n> \n> It is veriy unusual to get, even on two different platforms, both\n> messages for the same object.\n> \n> Could it be that you have i18n on \"Object %s is a %s, not a %s\" with\n> a wrong .po file that swaps the latter two parameters in the output?\nI'm using \nLANG=en_US.UTF-8\n\n> \n>>> What does \"git show 63499e4\" show when the test has failed?\n> \n> Was this question ever answered (I would prever \"cat-file -t\"\n> followed by \"cat-file \" instead of \"show\" for things like\n> this)? It should show that it is a blob whose contents is \"blob\\n\".\n\nThe question was never answered - I recently learnt that 63499e4 has been removed by this line: \n\ttest_when_finished \"remove_object $sha\" &&\nAnd when I remove that line in the modified test case, I get:\n=====================\nMac OS X, failed\n--------------\nfind . -name \"499e4*\" \n./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5\n\nfind . -name \"499e4*\" | xargs xxd\n0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\\..8\n0000010: 039e ..\n\ngit show 63499e4\nblob\n\ngit cat-file -t 63499e4\nblob\n\ngit cat-file blob 63499e4\nblob\n=========================\nMac OS X passed\n---------------\n~/projects/git/git.next/t/trash_directory.t1450-fsck2_120919_214913> ../../../errors_on_master/1450/junio.sh\nfind . -name \"499e4*\" \n./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5\n\nfind . -name \"499e4*\" | xargs xxd\n0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\\..8\n0000010: 039e ..\n\ngit show 63499e4\nblob\n\ngit cat-file -t 63499e4\nblob\n\ngit cat-file blob 63499e4\nblob\n\n==============\nLinux failed\n----------\nfind . -name \"499e4*\" \n./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5\n\nfind . -name \"499e4*\" | xargs xxd\n0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\\..8\n0000010: 039e ..\n\ngit show 63499e4\nblob\n\ngit cat-file -t 63499e4\nblob\n\ngit cat-file blob 63499e4\nblob\n==========================\nSo unless I'm too tired to see, there doesn't seem to be a difference\n[snip]\n>>\n>> diff failed passed\n>> diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out\n>> 17a18,20\n>>> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n>>> Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5\n>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit\n> \n> This is the correct behaviour.\n> \n>> 18a22,23\n>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links\n>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object\n> \n> This too.\n> \n>> 20,22d24\n>> < Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171\n>> < error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob\n>> < error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing\n\nOK, both are correct. But why isn't the \"broken links\" not detected?\nDoes fsck stop in one case, but continue in the other?\n\n/Torsten\n"},{"id":"200332","messageId":"506B110B.2050802@web.de","threadId":"31023","inReplyTo":"7va9wlhnl3.fsf@alter.siamese.dyndns.org","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-10-02T16:06:35Z","receivedAt":"2012-10-02T16:06:35Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 09/19/2012 08:30 PM, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n>\n> \"is a blob, not a commit\" is likely to come from validating of the\n> tag 66f6581d that presumably point at 63499e4; it reads the tag,\n> learns the name of the object that is tagged and the type of it,\n> remembers that the object pointed at (which it hasn't and is going\n> to validate next) _must_ be a commit (because tag says so) and then\n> realizes when it reads 63499e4 it is a blob and barfs.\n>\n> And that is what _should_ happen in that test. It crafts a\n> malformed tag that points at a blob and claims that it is a commit.\n> The test makes sure fsck catches that, and it does.\n>\n> On the other hand, \"is a commit, not a blob\", unless you have a tag\n> that directly points at a blob, is more likely to come from\n> validating some tree object. It reads the tree, learns the name of\n> the object contained in the tree and infers the type of that object\n> from the mode bits in the tree (100644 or 100755 would mean the\n> object must be a blob), goes on to validate that object and realizes\n> it is a commit and barfs.\n>\n\n\nThe good news:\nWith help of Junio's comments I probably found the reason why the test \nbehaves differently:\n\nThe objects are checked in a certain order, based on the inode number.\n\nWhich seems to be the same on most machines: when files are created\nin a certain order, then the inode numbers are in the same order.\n\nWhen the inode numbering changes for reasons known to the file system, \nthe order changes and fsck takes a different code path.\n\nTo provoke the error, the following helped at my Linux box:\n\ndiff --git a/builtin/fsck.c b/builtin/fsck.c\nindex a710227..bba8082 100644\n--- a/builtin/fsck.c\n+++ b/builtin/fsck.c\n@@ -373,7 +373,7 @@ static struct {\n\n static int ino_compare(const void *_a, const void *_b)\n {\n- const struct sha1_entry *a = _a, *b = _b;\n+ const struct sha1_entry *a = _b, *b = _a;\n unsigned long ino1 = a->ino, ino2 = b->ino;\n return ino1 < ino2 ? -1 : ino1 > ino2 ? 1 : 0;\n }\n\nThe bad news: I haven't found the time to prepare a fix.\n\n/Torsten\n"},{"id":"200369","messageId":"7v4nmc7fmz.fsf@alter.siamese.dyndns.org","threadId":"31023","inReplyTo":"506B110B.2050802@web.de","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T21:01:08Z","receivedAt":"2012-10-02T21:01:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> With help of Junio's comments I probably found the reason why the test\n> behaves differently:\n>\n> The objects are checked in a certain order, based on the inode number.\n>\n> Which seems to be the same on most machines: when files are created\n> in a certain order, then the inode numbers are in the same order.\n>\n> When the inode numbering changes for reasons known to the file system,\n> the order changes and fsck takes a different code path.\n>\n> To provoke the error, the following helped at my Linux box:\n>\n> diff --git a/builtin/fsck.c b/builtin/fsck.c\n> index a710227..bba8082 100644\n> --- a/builtin/fsck.c\n> +++ b/builtin/fsck.c\n> @@ -373,7 +373,7 @@ static struct {\n>\n> static int ino_compare(const void *_a, const void *_b)\n> {\n> - const struct sha1_entry *a = _a, *b = _b;\n> + const struct sha1_entry *a = _b, *b = _a;\n> unsigned long ino1 = a->ino, ino2 = b->ino;\n> return ino1 < ino2 ? -1 : ino1 > ino2 ? 1 : 0;\n> }\n>\n> The bad news: I haven't found the time to prepare a fix.\n\nThanks for a reproduction. Yes, the test t1450.13 is expecting too\nmuch.\n\nIf it finds the $sha blob first and then looks at $tag tag, then it\nwill notice that the tag is pointing at a blob but claims it must be\na commit. If it finds the $tag tag first, it will remember that the\ntag claimed $sha must be a commit, and when later it sees $sha, it\nfinds that it is not of the type it is expecting (namely, a commit),\nand says \"the object called $sha is broken\".\n\nSo \"test_must_fail git fsck --tags\" is correct. The fsck must find\nthe breakage either way.\n\nThe last piece to expect \"error in tag.*broken links\" in the output\nis wrong. Probably we should remove the misguided check and end\nit with \"test_must_fail git fsck --tags\".\n"},{"id":"200372","messageId":"7vy5jo5xco.fsf@alter.siamese.dyndns.org","threadId":"31023","inReplyTo":"7v4nmc7fmz.fsf@alter.siamese.dyndns.org","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T22:21:27Z","receivedAt":"2012-10-02T22:21:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The last piece to expect \"error in tag.*broken links\" in the output\n> is wrong. Probably we should remove the misguided check and end\n> it with \"test_must_fail git fsck --tags\".\n\nI think this should suffice.\n\nWhen we check tag T first, we make a mental note on X that is\nreferred by T that X must be of a certain type, but we do not bother\nrecording _why_ we decided X must be of the type (e.g. \"because tag\nT asks it to be\"). So when we check T and later check X, the only\nthing we know is that we expected X to be commit but it actually is\nblob. Exactly the same type of issue can arise for a blob that is\npointed by a tree or a tree that is pointed by a commit. If a tree\nrecords a reference to a commit but with 100644 mode bits, we may\neither say tree is broken (when we have already seen the referent\nand know it is a commit), or the referent is broken (when we saw the\ntree first and expect the referent to be a blob).\n\n-- >8 --\nSubject: [PATCH] t1450: the order the objects are checked is undefined\n\nWhen a tag T points at an object X that is of a type that is\ndifferent from what the tag records as, fsck should report it as an\nerror.\n\nHowever, depending on the order X and T are checked individually,\nthe actual error message can be different. If X is checked first,\nfsck remembers X's type and then when it checks T, it notices that T\nrecords X as a wrong type (i.e. the complaint is about a broken tag\nT). If T is checked first, on the other hand, fsck remembers that we\nneed to verify X is of the type tag records, and when it later\nchecks X, it notices that X is of a wrong type (i.e. the complaint\nis about a broken object X).\n\nThe important thing is that fsck notices such an error and diagnoses\nthe issue on object X, but the test was expecting that we happen to\ncheck objects in the order to make us detect issues with tag T, not\nwith object X. Remove this unwarranted assumption.\n\nSigned-off-by: Junio C Hamano \n---\n t/t1450-fsck.sh | 4 +---\n 1 file changed, 1 insertion(+), 3 deletions(-)\n\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nindex 5b79c51..9c64eef 100755\n--- a/t/t1450-fsck.sh\n+++ b/t/t1450-fsck.sh\n@@ -177,9 +177,7 @@ test_expect_success 'tag pointing to something else than its type' '\n \ttest_when_finished \"remove_object $tag\" &&\n \techo $tag >.git/refs/tags/wrong &&\n \ttest_when_finished \"git update-ref -d refs/tags/wrong\" &&\n-\ttest_must_fail git fsck --tags 2>out &&\n-\tcat out &&\n-\tgrep \"error in tag.*broken links\" out\n+\ttest_must_fail git fsck --tags\n '\n \n test_expect_success 'cleaned up' '\n-- \n1.8.0.rc0.54.g771a61b\n"},{"id":"200451","messageId":"506C940F.4010308@web.de","threadId":"31023","inReplyTo":"7vy5jo5xco.fsf@alter.siamese.dyndns.org","subject":"Re: t1450-fsck (sometimes/often) failes on Mac OS X","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-10-03T19:37:51Z","receivedAt":"2012-10-03T19:37:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 03.10.12 00:21, Junio C Hamano wrote:\n> I think this should suffice.\n> [snip]\n> -\ttest_must_fail git fsck --tags 2>out &&\n> -\tcat out &&\n> -\tgrep \"error in tag.*broken links\" out\n> +\ttest_must_fail git fsck --tags\n[snip]\n\nThanks, and all TC passed in pu.\n/Torsten\n"}]}