All of lore.kernel.org
 help / color / mirror / Atom feed
* Bug in reflog of length 0x2BFF
@ 2014-12-01 15:15 Christoph Mallon
  2014-12-01 16:00 ` Christoph Mallon
  2014-12-01 23:35 ` Jonathan Nieder
  0 siblings, 2 replies; 15+ messages in thread
From: Christoph Mallon @ 2014-12-01 15:15 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Hi,

I encountered a strange bug concerning the reflog.
I suspect some kind of out-of-bounds access.
The symptom is:

%git rev-parse 'master@{52}'
warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970
00:00:01 +0000.
0000000000000000000000000000000000000036

Try the following:

git init gitbug
cd gitbug
git commit --allow-empty -m a
cp ../reflog.bad .git/logs/refs/heads/master
git rev-parse 'master@{52}'

The source of cp is the attached file.
This is from a reflog of stash.
I just replaced all stuff by dummy values.
This does not seem to affect the bug.
Sorry, it must be this long.

Some observations:
* If you change the length of any line starting at line 3, the symptom
vanishes.
  (The XXXXX at the line ends are free-form text.)
* Starting at line three, there are 0x2BFF bytes till the end of file.
  Is there some dynamically growing buffer, which at some point reaches
the size 0x2C00?
* Changing the length of the first two lines has no effect.
  Is the file read backwards?
* It happens at least with git 2.1.2 (amd64) and 2.2.0 (ia32).
* 2.0.2 (amd64) and 2.1.0 (amd64) seem not to have this bug.


Any ideas?

	Christoph

[-- Attachment #2: reflog.bad --]
[-- Type: text/plain, Size: 11551 bytes --]

0000000000000000000000000000000000000037 0000000000000000000000000000000000000036 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	X
0000000000000000000000000000000000000036 0000000000000000000000000000000000000035 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	X
0000000000000000000000000000000000000035 0000000000000000000000000000000000000034 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000034 0000000000000000000000000000000000000033 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXX
0000000000000000000000000000000000000033 0000000000000000000000000000000000000032 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000032 0000000000000000000000000000000000000031 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000031 0000000000000000000000000000000000000030 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000030 000000000000000000000000000000000000002f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002f 000000000000000000000000000000000000002e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002e 000000000000000000000000000000000000002d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002d 000000000000000000000000000000000000002c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002c 000000000000000000000000000000000000002b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002b 000000000000000000000000000000000000002a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000002a 0000000000000000000000000000000000000029 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000029 0000000000000000000000000000000000000028 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000028 0000000000000000000000000000000000000027 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000027 0000000000000000000000000000000000000026 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000026 0000000000000000000000000000000000000025 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000025 0000000000000000000000000000000000000024 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000024 0000000000000000000000000000000000000023 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000023 0000000000000000000000000000000000000022 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000022 0000000000000000000000000000000000000021 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000021 0000000000000000000000000000000000000020 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000020 000000000000000000000000000000000000001f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001f 000000000000000000000000000000000000001e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001e 000000000000000000000000000000000000001d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001d 000000000000000000000000000000000000001c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001c 000000000000000000000000000000000000001b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001b 000000000000000000000000000000000000001a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000001a 0000000000000000000000000000000000000019 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000019 0000000000000000000000000000000000000018 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000018 0000000000000000000000000000000000000017 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000017 0000000000000000000000000000000000000016 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000016 0000000000000000000000000000000000000015 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000015 0000000000000000000000000000000000000014 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000014 0000000000000000000000000000000000000013 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000013 0000000000000000000000000000000000000012 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000012 0000000000000000000000000000000000000011 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000011 0000000000000000000000000000000000000010 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000010 000000000000000000000000000000000000000f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000f 000000000000000000000000000000000000000e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000e 000000000000000000000000000000000000000d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000d 000000000000000000000000000000000000000c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000c 000000000000000000000000000000000000000b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000b 000000000000000000000000000000000000000a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000000000000000000000000000000000000000a 0000000000000000000000000000000000000009 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000009 0000000000000000000000000000000000000008 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000008 0000000000000000000000000000000000000007 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000007 0000000000000000000000000000000000000006 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000006 0000000000000000000000000000000000000005 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000005 0000000000000000000000000000000000000004 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000004 0000000000000000000000000000000000000003 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000003 0000000000000000000000000000000000000002 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0000000000000000000000000000000000000002 0000000000000000000000000000000000000001 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  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 23:35 ` Jonathan Nieder
  1 sibling, 1 reply; 15+ messages in thread
From: Christoph Mallon @ 2014-12-01 16:00 UTC (permalink / raw)
  To: git

This commit seems to introduce the bug:
4207ed285f31ad3e04f08254237c0c1a1609642b

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-01 16:00 ` Christoph Mallon
@ 2014-12-01 18:53   ` Stefan Beller
  2014-12-01 22:30     ` Christoph Mallon
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Beller @ 2014-12-01 18:53 UTC (permalink / raw)
  To: Christoph Mallon; +Cc: git

So I am running a 3.13.0-40-generic x86_64 linux (so its's amd64) and
git version 2.1.2
and I cannot reproduce the bug you are describing. :(

$ git rev-parse 'master@{52}'
0000000000000000000000000000000000000035

What I noticed though is there are 2 linefeeds at the end of each
line, is that intended or did it break during transmission?

Stefan

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-01 18:53   ` Stefan Beller
@ 2014-12-01 22:30     ` Christoph Mallon
  0 siblings, 0 replies; 15+ messages in thread
From: Christoph Mallon @ 2014-12-01 22:30 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git, Junio C Hamano

Am 01.12.14 19:53, schrieb Stefan Beller:
> So I am running a 3.13.0-40-generic x86_64 linux (so its's amd64) and
> git version 2.1.2
> and I cannot reproduce the bug you are describing. :(

):

I can reproduce it with
* OS X, i386 binary, git 2.2.0
* FreeBSD, amd64, git 2.1.0 and up (bisected it there)
* FreeBSD, amd64, git 2.1.2 (different machine)

I cannot reproduce it with
* Linux, amd64, git 2.1.0

> $ git rev-parse 'master@{52}'
> 0000000000000000000000000000000000000035

On a machine, where you see the bug, you get entry /0...036/.
This btw causes havoc:
git stash list shows all entries, but e.g. git stash drop drops the
wrong stash after @{52}.

> What I noticed though is there are 2 linefeeds at the end of each
> line, is that intended or did it break during transmission?

That broke.
It should be a normal reflog file.
Try this:
	http://tron.yamagi.org/zeug/reflog.bad

Still 4207ed285f31ad3e04f08254237c0c1a1609642b seems a plausible cause,
because it's about reflogs.
Though I suspect the actual bug was introduced before, because this
commit only uses machinery, which was added earlier.

	Christoph

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-01 15:15 Bug in reflog of length 0x2BFF Christoph Mallon
  2014-12-01 16:00 ` Christoph Mallon
@ 2014-12-01 23:35 ` Jonathan Nieder
  2014-12-02  1:39   ` Stefan Beller
                     ` (2 more replies)
  1 sibling, 3 replies; 15+ messages in thread
From: Jonathan Nieder @ 2014-12-01 23:35 UTC (permalink / raw)
  To: Christoph Mallon; +Cc: git, Stefan Beller

Hi Christoph,

Christoph Mallon wrote:

> % git rev-parse 'master@{52}'
> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.
> 0000000000000000000000000000000000000036

Can you say more?  What output did you expect and how does this differ
from it?

I tried, with git 2.2.0,

	git init gitbug &&
	cd gitbug &&
	git commit --allow-empty -m a &&
	wget http://tron.yamagi.org/zeug/reflog.bad &&
	mv reflog.bad .git/logs/refs/heads/master &&
	sha1sum .git/logs/refs/heads/master &&
	git rev-parse 'master@{52}'

The output:

 9ffe44715d0e542a60916255f144c74e6760ffd0  .git/logs/refs/heads/master
 0000000000000000000000000000000000000035

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?

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  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
  2 siblings, 0 replies; 15+ messages in thread
From: Stefan Beller @ 2014-12-02  1:39 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Christoph Mallon, git

Hi,

so I have installed git version 2.2.0 currently, because I was trying to
reproduce "Bug in reflog of length 0x2BFF".

Now I was using git as a normal user, rebasing some stuff
(incidentally the reflog improvements)
and an error occurred:
$ git rebase --continue
error: Ref refs/heads/todo_sb13_ref-transactions-reflog-as-file is at
c48602d0aaa11b9099440c647ac028604fde4b14 but expected
d1bbdc6f161ae7550805d565cad1d930487dad34
fatal: update_ref failed for ref
'refs/heads/todo_sb13_ref-transactions-reflog-as-file': Cannot lock
the ref 'refs/heads/todo_sb13_ref-transactions-reflog-as-file'.

So I think we definitely have a bug in the reflog code already in version 2.2.0.

Trying to reproduce the error did not yield success.

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  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
  2 siblings, 0 replies; 15+ messages in thread
From: Christoph Mallon @ 2014-12-02  6:13 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: git, Stefan Beller

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Hi Jonathan,

Am 02.12.14 00:35, schrieb Jonathan Nieder:
> Christoph Mallon wrote:
>> % git rev-parse 'master@{52}'
>> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.
>> 0000000000000000000000000000000000000036
> 
> Can you say more?  What output did you expect and how does this differ
> from it?

sorry, I thought it is obvious that the warning should not be there.
As far as I understand the code, this warning is shown, when the old
commit id of one entry does not equal the new commit id of its predecessor.
But this reflog file does not have such a gap.
Also the correct result ist 0...035, not 0...036.
I.e. one entry is erroneously skipped.

> I tried, with git 2.2.0,
> 
> 	git init gitbug &&
> 	cd gitbug &&
> 	git commit --allow-empty -m a &&
> 	wget http://tron.yamagi.org/zeug/reflog.bad &&
> 	mv reflog.bad .git/logs/refs/heads/master &&
> 	sha1sum .git/logs/refs/heads/master &&
> 	git rev-parse 'master@{52}'

These steps look right.

> The output:
> 
>  9ffe44715d0e542a60916255f144c74e6760ffd0  .git/logs/refs/heads/master

The checksum is fine.

>  0000000000000000000000000000000000000035

You do not see the bug. |:

> 
> Could you make a test script that illustrates and reproduces the
> problem?  I.e., a patch to a file like t/t1410-reflog.sh [...]

http://tron.yamagi.org/zeug/0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch
(also attached)

This test works for me at v2.0.4 and fails at v2.1.0 and up (v2.2.0, the
current master).
Bisect says the symptom appears at 4207ed285f31ad3e04f08254237c0c1a1609642b.


	Christoph

[-- Attachment #2: 0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch --]
[-- Type: text/plain, Size: 12509 bytes --]

>From 82115da194adc42143b8603063e0a419fbbf4928 Mon Sep 17 00:00:00 2001
From: Christoph Mallon <christoph.mallon@gmx.de>
Date: Tue, 2 Dec 2014 07:03:11 +0100
Subject: [PATCH] t1410: Test erroneous skipping of reflog entries.

---
 t/t1410-reflog.sh | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index 8cf4461..cb77c27 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -287,4 +287,67 @@ test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '
 	test_cmp expect actual
 '
 
+test_expect_success 'erroneous skipping of reflog entries' '
+	git checkout -b reflogskip &&
+	cat > .git/logs/refs/heads/reflogskip <<EOF &&
+0000000000000000000000000000000000000037 0000000000000000000000000000000000000036 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	X
+0000000000000000000000000000000000000036 0000000000000000000000000000000000000035 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	X
+0000000000000000000000000000000000000035 0000000000000000000000000000000000000034 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000034 0000000000000000000000000000000000000033 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXX
+0000000000000000000000000000000000000033 0000000000000000000000000000000000000032 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000032 0000000000000000000000000000000000000031 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000031 0000000000000000000000000000000000000030 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000030 000000000000000000000000000000000000002f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002f 000000000000000000000000000000000000002e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002e 000000000000000000000000000000000000002d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002d 000000000000000000000000000000000000002c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002c 000000000000000000000000000000000000002b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002b 000000000000000000000000000000000000002a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000002a 0000000000000000000000000000000000000029 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000029 0000000000000000000000000000000000000028 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000028 0000000000000000000000000000000000000027 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000027 0000000000000000000000000000000000000026 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000026 0000000000000000000000000000000000000025 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000025 0000000000000000000000000000000000000024 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000024 0000000000000000000000000000000000000023 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000023 0000000000000000000000000000000000000022 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000022 0000000000000000000000000000000000000021 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000021 0000000000000000000000000000000000000020 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000020 000000000000000000000000000000000000001f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001f 000000000000000000000000000000000000001e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001e 000000000000000000000000000000000000001d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001d 000000000000000000000000000000000000001c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001c 000000000000000000000000000000000000001b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001b 000000000000000000000000000000000000001a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000001a 0000000000000000000000000000000000000019 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000019 0000000000000000000000000000000000000018 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000018 0000000000000000000000000000000000000017 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000017 0000000000000000000000000000000000000016 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000016 0000000000000000000000000000000000000015 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000015 0000000000000000000000000000000000000014 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000014 0000000000000000000000000000000000000013 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000013 0000000000000000000000000000000000000012 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000012 0000000000000000000000000000000000000011 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000011 0000000000000000000000000000000000000010 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000010 000000000000000000000000000000000000000f xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000f 000000000000000000000000000000000000000e xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000e 000000000000000000000000000000000000000d xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000d 000000000000000000000000000000000000000c xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000c 000000000000000000000000000000000000000b xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000b 000000000000000000000000000000000000000a xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+000000000000000000000000000000000000000a 0000000000000000000000000000000000000009 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000009 0000000000000000000000000000000000000008 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000008 0000000000000000000000000000000000000007 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000007 0000000000000000000000000000000000000006 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000006 0000000000000000000000000000000000000005 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000005 0000000000000000000000000000000000000004 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000004 0000000000000000000000000000000000000003 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000003 0000000000000000000000000000000000000002 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+0000000000000000000000000000000000000002 0000000000000000000000000000000000000001 xxxxxxxxxxxxxxxx <xxx@xxxxxxxxxxxxxxxxxxxxx> 0000000001 +0000	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+EOF
+	git rev-parse "@{52}" > actual 2>&1 &&
+	echo "0000000000000000000000000000000000000035" > expect &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.1.2


^ permalink raw reply related	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  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
  2 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2014-12-04 20:18 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Christoph Mallon, git, Stefan Beller

Jonathan Nieder <jrnieder@gmail.com> writes:

> Christoph Mallon wrote:
>
>> % git rev-parse 'master@{52}'
>> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.
>> 0000000000000000000000000000000000000036
>
> Can you say more?  What output did you expect and how does this differ
> from it?
>
> I tried, with git 2.2.0,
>
> 	git init gitbug &&
> 	cd gitbug &&
> 	git commit --allow-empty -m a &&
> 	wget http://tron.yamagi.org/zeug/reflog.bad &&
> 	mv reflog.bad .git/logs/refs/heads/master &&
> 	sha1sum .git/logs/refs/heads/master &&
> 	git rev-parse 'master@{52}'
>
> The output:
>
>  9ffe44715d0e542a60916255f144c74e6760ffd0  .git/logs/refs/heads/master
>  0000000000000000000000000000000000000035
>
> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-04 20:18   ` Junio C Hamano
@ 2014-12-04 20:37     ` Christoph Mallon
  2014-12-04 21:58       ` Jeff King
  2014-12-04 22:10       ` Bug in reflog of length 0x2BFF Junio C Hamano
  0 siblings, 2 replies; 15+ messages in thread
From: Christoph Mallon @ 2014-12-04 20:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jonathan Nieder, git, Stefan Beller

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.
I already sent a test-patch, here it is again:
	http://tron.yamagi.org/zeug/0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch
Using this test, bisect reliably gives
	4207ed285f31ad3e04f08254237c0c1a1609642b
as culprit.
It seems that Linux does not exhibit this particular behaviour.
Maybe there are differences in memory allocation, which mask the symptom.
Stefan Beller experienced some other sporadic bug regarding the reflog:
	http://marc.info/?l=git&m=141748434801505&w=2

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-04 20:37     ` Christoph Mallon
@ 2014-12-04 21:58       ` Jeff King
  2014-12-04 22:14         ` Junio C Hamano
  2014-12-04 22:10       ` Bug in reflog of length 0x2BFF Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Jeff King @ 2014-12-04 21:58 UTC (permalink / raw)
  To: Christoph Mallon; +Cc: Junio C Hamano, Jonathan Nieder, git, Stefan Beller

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

^ permalink raw reply related	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-04 20:37     ` Christoph Mallon
  2014-12-04 21:58       ` Jeff King
@ 2014-12-04 22:10       ` Junio C Hamano
  1 sibling, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2014-12-04 22:10 UTC (permalink / raw)
  To: Christoph Mallon; +Cc: Jonathan Nieder, git, Stefan Beller

Christoph Mallon <mallon@cs.uni-saarland.de> writes:

>> Amen to that.  I am getting the same thing.
>
> I ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,

Oh, I do not doubt you see a problem.  I am just saying that I don't
have an easy entry to the issue without it reproducing for me.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Bug in reflog of length 0x2BFF
  2014-12-04 21:58       ` Jeff King
@ 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
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2014-12-04 22:14 UTC (permalink / raw)
  To: Jeff King; +Cc: Christoph Mallon, Jonathan Nieder, git, Stefan Beller

Jeff King <peff@peff.net> writes:

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

Ahh, thanks for helping spot it.  A code that uses BUFSIZ explains
why a single reproduction recipe is platform dependent.

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

Sounds correct.  Unfortunately I no longer remember how I decided to
deal with a line that spans the block boundary in that piece of code
X-<.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* [PATCH] for_each_reflog_ent_reverse: fix newlines on block boundaries
  2014-12-04 22:14         ` Junio C Hamano
@ 2014-12-05  1:28           ` Jeff King
  2014-12-05  1:32             ` [PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion Jeff King
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff King @ 2014-12-05  1:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Christoph Mallon, Jonathan Nieder, git, Stefan Beller

On Thu, Dec 04, 2014 at 02:14:50PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > 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.
> 
> Ahh, thanks for helping spot it.  A code that uses BUFSIZ explains
> why a single reproduction recipe is platform dependent.

It also makes writing portable tests annoying, but I think I managed it
in the patch below. :)

> > 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.
> > ...
> > 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).
> 
> Sounds correct.  Unfortunately I no longer remember how I decided to
> deal with a line that spans the block boundary in that piece of code
> X-<.

Here's my proposed fix.

-- >8 --
When we read a reflog file in reverse, we read whole chunks
of BUFSIZ bytes, then loop over the buffer, parsing any
lines we find. We find the beginning of each line by looking
for the newline from the previous line. If we don't find
one, we know that we are either at the beginning of
the file, or that we have to read another block.

In the latter case, we stuff away what we have into a
strbuf, read another block, and continue our parse. But we
missed one case here. If we did find a newline, and it is at
the beginning of the block, we must also stuff that newline
into the strbuf, as it belongs to the block we are about to
read.

The minimal fix here would be to add this special case to
the conditional that checks whether we found a newline.
But we can make the flow a little clearer by rearranging a
bit: we first handle lines that we are going to show, and
then at the end of each loop, stuff away any leftovers if
necessary. That lets us fold this special-case in with the
more common "we ended in the middle of a line" case.

Signed-off-by: Jeff King <peff@peff.net>
---
I really needed this rearranging to figure out what the fix
_should_ be. Now that I did that, I was able to write the above
paragraph explaining what the minimal fix would be. And I can do that if
we prefer. But I think the fact that I had to go through the untangling
step first is an indication that maybe the end result is better. Of
course that's all subjective. :)

I waffled on the test script between generating it on the fly (as
below), and just including a complete 8K example that provokes the
failure. I don't care about the size that much, but rather on which is
more readable. My goal with showing the generation steps was to make it
clear how we arrived there, but I fear it may have ended up too
convoluted to do anyone any good. Opinions welcome.

 refs.c            | 47 ++++++++++++++++++++++++++++++++++++-----------
 t/t1410-reflog.sh | 30 ++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/refs.c b/refs.c
index 5ff457e..ccb8834 100644
--- a/refs.c
+++ b/refs.c
@@ -3404,24 +3404,49 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void
 
 			bp = find_beginning_of_line(buf, scanp);
 
-			if (*bp != '\n') {
-				strbuf_splice(&sb, 0, 0, buf, endp - buf);
-				if (pos)
-					break; /* need to fill another block */
-				scanp = buf - 1; /* leave loop */
-			} else {
+			if (*bp == '\n') {
 				/*
-				 * (bp + 1) thru endp is the beginning of the
-				 * current line we have in sb
+				 * The newline is the end of the previous line,
+				 * so we know we have complete line starting
+				 * at (bp + 1). Prefix it onto any prior data
+				 * we collected for the line and process it.
 				 */
 				strbuf_splice(&sb, 0, 0, bp + 1, endp - (bp + 1));
 				scanp = bp;
 				endp = bp + 1;
+				ret = show_one_reflog_ent(&sb, fn, cb_data);
+				strbuf_reset(&sb);
+				if (ret)
+					break;
+			} else if (!pos) {
+				/*
+				 * We are at the start of the buffer, and the
+				 * start of the file; there is no previous
+				 * line, and we have everything for this one.
+				 * Process it, and we can end the loop.
+				 */
+				strbuf_splice(&sb, 0, 0, buf, endp - buf);
+				ret = show_one_reflog_ent(&sb, fn, cb_data);
+				strbuf_reset(&sb);
+				break;
 			}
-			ret = show_one_reflog_ent(&sb, fn, cb_data);
-			strbuf_reset(&sb);
-			if (ret)
+
+			if (bp == buf) {
+				/*
+				 * We are at the start of the buffer, and there
+				 * is more file to read backwards. Which means
+				 * we are in the middle of a line. Note that we
+				 * may get here even if *bp was a newline; that
+				 * just means we are at the exact end of the
+				 * previous line, rather than some spot in the
+				 * middle.
+				 *
+				 * Save away what we have to be combined with
+				 * the data from the next read.
+				 */
+				strbuf_splice(&sb, 0, 0, buf, endp - buf);
 				break;
+			}
 		}
 
 	}
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index 8cf4461..779d4e3 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -287,4 +287,34 @@ test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '
 	test_cmp expect actual
 '
 
+# Triggering the bug detected by this test requires a newline to fall
+# exactly BUFSIZ-1 bytes from the end of the file. We don't know
+# what that value is, since it's platform dependent. However, if
+# we choose some value N, we also catch any D which divides N evenly
+# (since we will read backwards in chunks of D). So we choose 8K,
+# which catches glibc (with an 8K BUFSIZ) and *BSD (1K).
+#
+# Each line is 114 characters, so we need 75 to still have a few before the
+# last 8K. The 89-character padding on the final entry lines up our
+# newline exactly.
+test_expect_success 'parsing reverse reflogs at BUFSIZ boundaries' '
+	git checkout -b reflogskip &&
+	z38=00000000000000000000000000000000000000 &&
+	ident="abc <xyz> 0000000001 +0000" &&
+	for i in $(test_seq 1 75); do
+		printf "$z38%02d $z38%02d %s\t" $i $(($i+1)) "$ident" &&
+		if test $i = 75; then
+			for j in $(test_seq 1 89); do
+				printf X
+			done
+		else
+			printf X
+		fi &&
+		printf "\n"
+	done >.git/logs/refs/heads/reflogskip &&
+	git rev-parse reflogskip@{73} >actual &&
+	echo ${z38}03 >expect &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.2.0.390.gf60752d

^ permalink raw reply related	[flat|nested] 15+ messages in thread
* [PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion
  2014-12-05  1:28           ` [PATCH] for_each_reflog_ent_reverse: fix newlines on block boundaries Jeff King
@ 2014-12-05  1:32             ` Jeff King
  2014-12-05 19:15               ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff King @ 2014-12-05  1:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Christoph Mallon, Jonathan Nieder, git, Stefan Beller

On Thu, Dec 04, 2014 at 08:28:54PM -0500, Jeff King wrote:

> The minimal fix here would be to add this special case to
> the conditional that checks whether we found a newline.
> But we can make the flow a little clearer by rearranging a
> bit: we first handle lines that we are going to show, and
> then at the end of each loop, stuff away any leftovers if
> necessary. That lets us fold this special-case in with the
> more common "we ended in the middle of a line" case.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I really needed this rearranging to figure out what the fix
> _should_ be. Now that I did that, I was able to write the above
> paragraph explaining what the minimal fix would be. And I can do that if
> we prefer. But I think the fact that I had to go through the untangling
> step first is an indication that maybe the end result is better. Of
> course that's all subjective. :)

I _think_ the patch below is also applicable to the code before my
boundary-fixing patch. But the rearranging also made me more confident
in it.

-- >8 --
Subject: for_each_reflog_ent_reverse: turn leftover check into assertion

Our loop should always process all lines, even if we hit the
beginning of the file. We have a conditional after the loop
ends to double-check that there is nothing left and to
process it. But this should never happen, and is a sign of a
logic bug in the loop. Let's turn it into a BUG assertion.

Signed-off-by: Jeff King <peff@peff.net>
---
Of course I cannot say something like "this can never happen; the old
code was wrong to handle this case" without a nagging feeling that I am
missing something, so extra careful eyes are appreciated (and are why I
would rather have an assert here than removing the code and silently
dropping lines if I am wrong).

 refs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/refs.c b/refs.c
index ccb8834..1f77fa6 100644
--- a/refs.c
+++ b/refs.c
@@ -3451,7 +3451,7 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void
 
 	}
 	if (!ret && sb.len)
-		ret = show_one_reflog_ent(&sb, fn, cb_data);
+		die("BUG: reverse reflog parser had leftover data");
 
 	fclose(logfp);
 	strbuf_release(&sb);
-- 
2.2.0.390.gf60752d

^ permalink raw reply related	[flat|nested] 15+ messages in thread
* Re: [PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion
  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
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2014-12-05 19:15 UTC (permalink / raw)
  To: Jeff King; +Cc: Christoph Mallon, Jonathan Nieder, git, Stefan Beller

Jeff King <peff@peff.net> writes:

> I _think_ the patch below is also applicable to the code before my
> boundary-fixing patch. But the rearranging also made me more confident
> in it.

Yeah, thanks for a fix.

> -- >8 --
> Subject: for_each_reflog_ent_reverse: turn leftover check into assertion
>
> Our loop should always process all lines, even if we hit the
> beginning of the file. We have a conditional after the loop
> ends to double-check that there is nothing left and to
> process it. But this should never happen, and is a sign of a
> logic bug in the loop. Let's turn it into a BUG assertion.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Of course I cannot say something like "this can never happen; the old
> code was wrong to handle this case" without a nagging feeling that I am
> missing something, so extra careful eyes are appreciated (and are why I
> would rather have an assert here than removing the code and silently
> dropping lines if I am wrong).
>
>  refs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/refs.c b/refs.c
> index ccb8834..1f77fa6 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3451,7 +3451,7 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void
>  
>  	}
>  	if (!ret && sb.len)
> -		ret = show_one_reflog_ent(&sb, fn, cb_data);
> +		die("BUG: reverse reflog parser had leftover data");
>  
>  	fclose(logfp);
>  	strbuf_release(&sb);

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-12-05 19:15 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.