git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: Jeff King <peff@peff.net>, Git mailing list <git@vger.kernel.org>
Subject: Re: Bug in fetch-pack.c, please confirm
Date: Sun, 15 Mar 2015 00:27:25 -0700	[thread overview]
Message-ID: <xmqqa8zevhya.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <0758b2029b41448a77a4e4df1c4e406@74d39fa044aa309eaea14b9f57fe79c> (Kyle J. McKay's message of "Sat, 14 Mar 2015 23:37:37 -0700")

"Kyle J. McKay" <mackyle@gmail.com> writes:

> Hi guys,
>
> So I was looking at fetch-pack.c (from master @ 52cae643, but I think  
> it's the same everywhere):
>
> # Lines 626-648
>

49bb805e (Do not ask for objects known to be complete., 2005-10-19)
seems to lose the assignment to local[].

> Something's very wrong here.
>
> It looks to me like the bug was introduced in 49bb805e (Do not ask for  
> objects known to be complete. 2005-10-19).

I read that "lines 626-648", stopped reading your message and did a
blame session myself, and arrived at the same culprit.

The very original code that read from the ref directly here; I do
not think it was an attempt to catch a race condition where
ref->old_sha1 got stale and the ref on the filesystem has a newer
value.  Hence, I think copying from o->sha1 like you did is a fix
that is the most faithful to the original code.

o is lookup_object(remote) which is lookup_object(ref->old_sha1);
that makes o->sha1 always be ref->old_sha1, so either would be fine,
but o->sha1 would be more appropriate in this codeflow.  We grab o,
if it is NULL or if we do not like it, we do something and continue,
otherwise we like that o so grabbing o->sha1 out of it makes the
logic look flowing right, at least to me ;-)

> -- 8< --
> Subject: [PATCH] fetch-pack.c: do not use uninitialized sha1 value
>
> Since 49bb805e (Do not ask for objects known to be complete. 2005-10-19)
> when the read_ref call was replaced with a parse_object call, the
> automatic variable 'local' containing an sha1 has been left uninitialized.
>
> Subsequently in 1baaae5e (Make maximal use of the remote refs, 2005-10-28)
> the parse_object call was replaced with a lookup_object call but still
> the 'local' variable was left uninitialized.
>
> However, it's used as the source to update another sha1 value in the case
> that we already have it and in that case the other ref will end up with
> whatever garbage was in the 'local' variable.
>
> Fix this by removing the 'local' variable and using the value from the
> result of the lookup_object call instead.
>
> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
> ---
>  fetch-pack.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 655ee642..c0b4d84f 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -621,29 +621,28 @@ static int everything_local(struct fetch_pack_args *args,
>  		}
>  	}
>  
>  	filter_refs(args, refs, sought, nr_sought);
>  
>  	for (retval = 1, ref = *refs; ref ; ref = ref->next) {
>  		const unsigned char *remote = ref->old_sha1;
> -		unsigned char local[20];
>  		struct object *o;
>  
>  		o = lookup_object(remote);
>  		if (!o || !(o->flags & COMPLETE)) {
>  			retval = 0;
>  			if (!args->verbose)
>  				continue;
>  			fprintf(stderr,
>  				"want %s (%s)\n", sha1_to_hex(remote),
>  				ref->name);
>  			continue;
>  		}
>  
> -		hashcpy(ref->new_sha1, local);
> +		hashcpy(ref->new_sha1, o->sha1);
>  		if (!args->verbose)
>  			continue;
>  		fprintf(stderr,
>  			"already have %s (%s)\n", sha1_to_hex(remote),
>  			ref->name);
>  	}
>  	return retval;
> ---

  reply	other threads:[~2015-03-15  7:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-15  6:37 Bug in fetch-pack.c, please confirm Kyle J. McKay
2015-03-15  7:27 ` Junio C Hamano [this message]
2015-03-15  7:30   ` Junio C Hamano
2015-03-15 22:21     ` Kyle J. McKay
2015-03-16  1:13 ` Jeff King
2015-03-19 17:41   ` Junio C Hamano
2015-03-19 18:55     ` Jeff King
2015-03-19 19:01       ` Junio C Hamano
2015-03-19 20:31         ` Jeff King
2015-03-19 20:34           ` [PATCH 1/4] filter_ref: avoid overwriting ref->old_sha1 with garbage Jeff King
2015-03-19 21:09             ` Junio C Hamano
2015-03-19 20:37           ` [PATCH 2/4] filter_ref: make a copy of extra "sought" entries Jeff King
2015-03-19 20:38           ` [PATCH 3/4] fetch_refs_via_pack: free extra copy of refs Jeff King
2015-03-19 20:39           ` [PATCH 4/4] fetch-pack: remove dead assignment to ref->new_sha1 Jeff King

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=xmqqa8zevhya.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mackyle@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).