All of lore.kernel.org
 help / color / mirror / Atom feed
From: Siddharth Agarwal <sid0@fb.com>
To: Jeff King <peff@peff.net>
Cc: <git@vger.kernel.org>, <bmaurer@fb.com>, Aaron Kushner <akushner@fb.com>
Subject: Re: with reuse-delta patches, fetching with bitmaps segfaults due to possibly incomplete bitmap traverse
Date: Sun, 23 Mar 2014 17:01:00 -0700	[thread overview]
Message-ID: <532F75BC.7080301@fb.com> (raw)
In-Reply-To: <20140322125626.GA22890@sigill.intra.peff.net>

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
> objects.

The patch does stop Git from segfaulting. I know too little to judge its 
correctness, though.

>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 9fc5321..ca1b0f7 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -1437,6 +1437,7 @@ static void check_object(struct object_entry *entry)
>   			entry->delta = xcalloc(1, sizeof(*entry->delta));
>   			hashcpy(entry->delta->idx.sha1, base_ref);
>   			entry->delta->preferred_base = 1;
> +			entry->delta->filled = 1;
>   			unuse_pack(&w_curs);
>   			return;
>   		}
>
> -Peff

  reply	other threads:[~2014-03-24  0:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22  2:58 with reuse-delta patches, fetching with bitmaps segfaults due to possibly incomplete bitmap traverse Siddharth Agarwal
2014-03-22 12:56 ` Jeff King
2014-03-24  0:01   ` Siddharth Agarwal [this message]
2014-03-24 20:30   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=532F75BC.7080301@fb.com \
    --to=sid0@fb.com \
    --cc=akushner@fb.com \
    --cc=bmaurer@fb.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.