On 03/22/2014 05:56 AM, Jeff King wrote:
On Fri, Mar 21, 2014 at 07:58:55PM -0700, Siddharth Agarwal wrote:
Is it also reproducible just with the tip of "next"? Note that the
patches in jk/bitmap-reuse-delta have not been widely deployed (in
particular, we are not yet using them at GitHub, and we track segfaults
on our servers closely and have not seen any related to this).
I cannot reproduce this with the tip of next (tested with 4443bfd).
That's also -- unsurprisingly -- significantly slower in the
compression phase and sends much more data (3x for the pair of repos in
the OP) over the wire than a Git that doesn't use bitmaps.
Those patches allocate extra "fake" entries in the entry->delta fields,
which are not accounted for in to_pack.nr_objects. It's entirely
possible that those entries are related to the bug you are seeing.
That sounds like it could be the problem, yes.
Hmm, yeah, that confirms my suspicion. In the earlier loops, we call
add_to_write_order, which only adds the object in question, and can
never exceed to_pack.nr_objects. In this final loop, we call
add_family_to_write_order, which is going to add any deltas that were
not already included.
The patch below may fix your problem, but I have a feeling it is not the
right thing to do. The point of 81cdec28 is to try to point to a delta
entry as if it were a "preferred base" (i.e., something we know that the
other side has already). We perhaps want to add these entries to the
actual packing list, and skip them as we do with normal preferred_base
The patch does stop Git from segfaulting. I know too little to judge its
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 9fc5321..ca1b0f7 100644
@@ -1437,6 +1437,7 @@ static void check_object(struct object_entry *entry)
entry->delta = xcalloc(1, sizeof(*entry->delta));
entry->delta->preferred_base = 1;
+ entry->delta->filled = 1;
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html