All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
To: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, pclouds@gmail.com
Subject: Re: [PATCH v3] reflog-walk: don't segfault on non-commit sha1's in the reflog
Date: Thu, 31 Dec 2015 09:57:07 +0100	[thread overview]
Message-ID: <1451552227.11138.6.camel@kaarsemaker.net> (raw)
In-Reply-To: <xmqq37ujcwny.fsf@gitster.mtv.corp.google.com>

On wo, 2015-12-30 at 16:02 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
> 
> > diff --git a/reflog-walk.c b/reflog-walk.c
> > index 85b8a54..0ebd1da 100644
> > --- a/reflog-walk.c
> > +++ b/reflog-walk.c
> > @@ -221,6 +221,7 @@ void fake_reflog_parent(struct reflog_walk_info
> > *info, struct commit *commit)
> >  	struct commit_info *commit_info =
> >  		get_commit_info(commit, &info->reflogs, 0);
> >  	struct commit_reflog *commit_reflog;
> > +	struct object *logobj;
> 
> This thing is not initialized...
> 
> >  	struct reflog_info *reflog;
> >  
> >  	info->last_commit_reflog = NULL;
> > @@ -232,15 +233,20 @@ void fake_reflog_parent(struct
> > reflog_walk_info *info, struct commit *commit)
> >  		commit->parents = NULL;
> >  		return;
> >  	}
> > -
> > -	reflog = &commit_reflog->reflogs->items[commit_reflog
> > ->recno];
> >  	info->last_commit_reflog = commit_reflog;
> > -	commit_reflog->recno--;
> > -	commit_info->commit = (struct commit *)parse_object(reflog
> > ->osha1);
> > -	if (!commit_info->commit) {
> > +
> > +	do {
> > +		reflog = &commit_reflog->reflogs
> > ->items[commit_reflog->recno];
> > +		commit_reflog->recno--;
> > +		logobj = parse_object(reflog->osha1);
> > +	} while (commit_reflog->recno && (logobj && logobj->type
> > != OBJ_COMMIT));
> 
> But this loop runs at least once, so logobj will always have some
> sane value when the loop exits.
> 
> > +	if (!logobj || logobj->type != OBJ_COMMIT) {
> 
> And the only case where this should trigger is when we ran out of
> recno.  Am I reading the updated code correctly?

Yes, your description matches what I tried to implement.

> With the updated code, the number of times we return from this
> function is different from the number initially set to recno.  I had
> to wonder if the caller cares and misbehaves, but the caller does
> not know how long the reflog is before starting to call
> get_revision() in a loop anyway, so it already has to deal with a
> case where it did .recno=20 and get_revision() did not return that
> many times.  So this probably is safe.

That corresponds to what I see when experimenting with different
reflogs.

> > +test_expect_success 'reflog containing non-commit sha1s displays
> > properly' '
> 
> In general, "properly" is a poor word to use in test description (or
> a commit log message or a bug report, for that matter), as the whole
> point of a test is to precisely define what is "proper".
> 
> And the code change declares that a proper thing to do is to omit
> non-commit entries without segfaulting, so something like
> 
>     s/displays properly/omits them/
> 
> perhaps?

I did find the test title a bit iffy but couldn't really figure out
why. What you're saying makes a lot of sense, will fix.
-- 
Dennis Kaarsemaker
www.kaarsemaker.net

  reply	other threads:[~2015-12-31  8:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30  9:24 Segfault in git reflog Dennis Kaarsemaker
2015-12-30 10:31 ` Duy Nguyen
2015-12-30 11:17 ` Dennis Kaarsemaker
2015-12-30 11:26   ` Duy Nguyen
2015-12-30 11:28     ` Duy Nguyen
2015-12-30 12:28       ` Dennis Kaarsemaker
2015-12-30 13:19         ` Duy Nguyen
2015-12-30 15:22           ` [PATCH] reflog-walk: don't segfault on non-commit sha1's in the reflog Dennis Kaarsemaker
2015-12-30 21:20             ` Junio C Hamano
2015-12-30 21:33               ` Dennis Kaarsemaker
2015-12-30 21:41                 ` Junio C Hamano
2015-12-30 21:49                   ` Dennis Kaarsemaker
2015-12-30 22:17                     ` [PATCH v2] " Dennis Kaarsemaker
2015-12-30 22:42                       ` Junio C Hamano
2015-12-30 23:33                         ` [PATCH v3] " Dennis Kaarsemaker
2015-12-31  0:02                           ` Junio C Hamano
2015-12-31  8:57                             ` Dennis Kaarsemaker [this message]
2015-12-31 15:43                               ` Dennis Kaarsemaker
2016-01-05 21:12                               ` [PATCH v4] " Dennis Kaarsemaker
2016-01-06  1:05                                 ` Eric Sunshine
2016-01-06  1:20                                   ` Dennis Kaarsemaker
2016-01-06  1:28                                     ` Eric Sunshine
2016-01-06  1:52                                       ` Eric Sunshine
2016-01-06  9:13                                         ` Dennis Kaarsemaker
2016-01-06  9:30                                           ` Duy Nguyen

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=1451552227.11138.6.camel@kaarsemaker.net \
    --to=dennis@kaarsemaker.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /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.