git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Christoph Mallon <mallon@cs.uni-saarland.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>
Subject: Re: Bug in reflog of length 0x2BFF
Date: Thu, 4 Dec 2014 16:58:05 -0500	[thread overview]
Message-ID: <20141204215805.GD19953@peff.net> (raw)
In-Reply-To: <5480C60E.3070903@cs.uni-saarland.de>

On Thu, Dec 04, 2014 at 09:37:34PM +0100, Christoph Mallon wrote:

> Am 04.12.14 21:18, schrieb Junio C Hamano:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >> Could you make a test script that illustrates and reproduces the
> >> problem?  I.e., a patch to a file like t/t1410-reflog.sh, such that
> >> if I run
> >>
> >> 	cd git
> >> 	make
> >> 	cd t
> >> 	./t1410-reflog.sh
> >>
> >> then I can reproduce the bug?
> > 
> > Amen to that.  I am getting the same thing.
> 
> I ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,
> amd64), a friend of mine can, too.

Thanks, I was able to reproduce this easily on an OS X machine.

Does this patch fix your problem?

diff --git a/refs.c b/refs.c
index f1afec5..42e3a30 100644
--- a/refs.c
+++ b/refs.c
@@ -3052,7 +3052,7 @@ static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *c
 	int tz;
 
 	/* old SP new SP name <email> SP time TAB msg LF */
-	if (sb->len < 83 || sb->buf[sb->len - 1] != '\n' ||
+	if (sb->len < 83 ||
 	    get_sha1_hex(sb->buf, osha1) || sb->buf[40] != ' ' ||
 	    get_sha1_hex(sb->buf + 41, nsha1) || sb->buf[81] != ' ' ||
 	    !(email_end = strchr(sb->buf + 82, '>')) ||


I think the bug is in the reverse-reflog reader in
for_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in
reverse order, and then parses them individually. If the trailing
newline for a line falls directly on the block boundary, we may not have
it in our current block, and pass the line to show_one_reflog_ent
without a trailing newline. That function is picky about making sure it
got a full line.

So this is a long-standing bug in for_each_reflog_ent_reverse. It just
showed up recently because we started using that function for
read_ref_at_ent.

I haven't confirmed yet, but I suspect the problem shows up on OS X and
FreeBSD but not Linux because of the definition of BUFSIZ (so it is
really probably glibc versus BSD libc). The same bug exists on Linux,
but you would need different input to stimulate the newline at the right
spot.

The above is a workaround. I think the right solution is probably to
teach for_each_reflog_ent_reverse to makes sure the trailing newline is
included (either by tweaking the reverse code, or conditionally adding
it to the parsed buffer).

-Peff

  reply	other threads:[~2014-12-04 21:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 15:15 Bug in reflog of length 0x2BFF Christoph Mallon
2014-12-01 16:00 ` Christoph Mallon
2014-12-01 18:53   ` Stefan Beller
2014-12-01 22:30     ` Christoph Mallon
2014-12-01 23:35 ` Jonathan Nieder
2014-12-02  1:39   ` Stefan Beller
2014-12-02  6:13   ` Christoph Mallon
2014-12-04 20:18   ` Junio C Hamano
2014-12-04 20:37     ` Christoph Mallon
2014-12-04 21:58       ` Jeff King [this message]
2014-12-04 22:14         ` Junio C Hamano
2014-12-05  1:28           ` [PATCH] for_each_reflog_ent_reverse: fix newlines on block boundaries Jeff King
2014-12-05  1:32             ` [PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion Jeff King
2014-12-05 19:15               ` Junio C Hamano
2014-12-04 22:10       ` Bug in reflog of length 0x2BFF 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=20141204215805.GD19953@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=mallon@cs.uni-saarland.de \
    --cc=sbeller@google.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 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).