Peff, thanks for looking into this.
My answers are inline and at the end.
On 15.07.12 11:08, Jeff King wrote:
> 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?
../../git show 63499e4
blob
> 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)?
../../git fsck --tags
Checking object directories: 100% (256/256), done.
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
broken link from tag 66f6581d549f70e05ca586bc2df5c15a95662c36
broken link from unknown unknown
dangling blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
>
>> 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.
../../git ls-files -s
100644 5626abf0f72e58d7a153368ba57db4c673c0e171 0 fileA
100644 f719efd430d52bcfc8566a43b2eb655688d38871 0 fileB
I did some bisecting, and it didn't lead to a bad commit.
The problem goes away after another clone into a fresh directory.
Once it comes up, it seems to stay within that working tree.
Or it has something to do with the uptime of the machine (?)
Checking out v1.7.10 seems to make the problem go away, and
stepping up to e.g.
>commit d30ef5144cee3e9ed01a2a3f3b96d47c5322b20d
> Merge branch 'jc/sha1-name-more' into next
brings the failure back.
This is probably not related to this very 2 commits, so may be a
"reverse bisect" would help, ("When does the problem go away?")
Thanks for helping
/Torsten
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html