Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > Is there some easy way to tell what object it was having problems with > when it failed to unpack? I've got a whole lot of objects. Can you use gdb to find it? If so, walk up the stack into fast-import.c's load_tree() function and look at sha1 here, and also, *myoe. > The expected size of the base is 1882, while the actual size is 151. The > base offset it found was 12. > > I'm using "checkpoint" a lot, so I've got 24 packs. Two of them have tree > objects of size 1882 at offset 12; a different one has a tree object of > size 151 at offset 12. The one with the object of size 151 was the one > that was still open at the end. There's no tree of size 1882 in this pack, > nor in any other pack that has a tree of size 151. > > So maybe it's right about the offsets and all, but it's confused about > which pack something was in? Maybe it cached something when the pack > containing the object it wants was open, and it ended up thinking it was > in the pack that's now open rather than the pack that was open and is now > closed? fast-import keeps all of its object data in a single table of "struct object_entry", the table is keyed by SHA-1. Each entry has a pack_id, which tells it which pack this object is in, and the offset of the object within that pack. Sounds like maybe its confusing the pack pointer in the all_packs array (see gfi_unpack_entry). > I don't suppose there would be an easy way to figure out the object it was > trying to unpack by applying the delta? Not really. You'd have to write code for this. Or, since the pack closes and you can index it, use "verify-pack -v" to find the object starting at the offset you know its having trouble with, that should tell you the object's SHA-1. -- Shawn. -- 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
