Hi,
We're still experimenting with bitmaps, and we've have run into issues
where fetching from a repository with bitmaps enabled can lead to
objects that used to be present on the server but have since been GC'd
being accessed, and git pack-objects on the server failing because of that.
I can consistently reproduce this with a particular pair of repos, and
tip of git master (3f09db0) with no patches on top running on both ends.
git fetch fails with
remote: error: Could not read be7cbe440a7b9a34f53515af4075e971c811cfb2
remote: fatal: bad tree object be7cbe440a7b9a34f53515af4075e971c811cfb2
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
Removing the bitmap fixes this.
be7cbe440a7b9a34f53515af4075e971c811cfb2 is a tree object that is
present on the client but not on the server. It used to be present on
the server, but the any refs that it was reachable from have been
removed and the object has since been garbage collected. One ref that
this object was reachable from and that used to be on the server is
still present on the client though, under refs/remotes/origin/.
This tree object seems to be reachable from exactly one other tree
object, and so on, until I reach a commit object. Note that the commit
and root tree pointing to be7cbe440a7b9a34f53515af4075e971c811cfb2 is
still present as a loose object in the repo.
I dug into this a bit, and it looks like the bad access is inside
https://github.com/git/git/blob/3f09db0/pack-bitmap.c#L730, and from
there inside https://github.com/git/git/blob/3f09db0/pack-bitmap.c#L575.
This ultimately calls traverse_commit_list at
https://github.com/git/git/blob/3f09db0/list-objects.c#L195, which adds
the tree that transitively points to
be7cbe440a7b9a34f53515af4075e971c811cfb2 as pending. (Note again that
the commit and root tree objects still exist in the repo as loose
objects.) Further down in that function, process_tree is called, which
traverses the tree and ultimately dies at
https://github.com/git/git/blob/3f09db0/list-objects.c#L85.
Unfortunately, as before, I can't share the repo this is happening in.
--
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