Re: Bug in reflog of length 0x2BFF
Am 04.12.14 21:18, schrieb Junio C Hamano: Jonathan Nieder jrnie...@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=gitm=141748434801505w=2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in reflog of length 0x2BFF
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 +.
0036
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 X 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
0037
0036
xxx@xxx 01 + X
0036
0035
xxx@xxx 01 + X
0035
0034
xxx@xxx 01 +
0034
0033
xxx@xxx 01 + XXX
0033
0032
xxx@xxx 01 +
XX
0032
0031
xxx@xxx 01 +
X
0031
0030
xxx@x 01 +
XX
0030
002f
xxx@x 01 +
XXX
002f
002e
xxx@x 01 +
XXX
002e
002d
xxx@x 01 +
002d
002c
xxx@x 01 +
XXX
002c
002b
xxx@x 01 +
XXX
002b
002a
xxx@x 01 +
X
002a
0029
xxx@x 01 +
XXX
0029
0028
xxx@x 01 +
XX
0028
0027
xxx@x 01 +
XXX
0027
0026
xxx@x 01 +
XXX
0026
0025
xxx@x 01 +
XXX
0025
0024
xxx@x
Re: Bug in reflog of length 0x2BFF
This commit seems to introduce the bug: 4207ed285f31ad3e04f08254237c0c1a1609642b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in reflog of length 0x2BFF
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}'
0035
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in reflog of length 0x2BFF
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 +.
0036
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.
0035
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
From 82115da194adc42143b8603063e0a419fbbf4928 Mon Sep 17 00:00:00 2001
From: Christoph Mallon christoph.mal...@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
+0037
0036
xxx@xxx 01 + X
+0036
0035
xxx@xxx 01 + X
+0035
0034
xxx@xxx 01 +
+0034
0033
xxx@xxx 01 + XXX
+0033
0032
xxx@xxx 01 +
XX
+0032
0031
xxx@xxx 01 +
X
+0031
0030
xxx@x 01 +
XX
+0030
002f
xxx@x 01 +
XXX
+002f
002e
xxx@x 01 +
XXX
+002e
002d
xxx@x 01 +
+002d
002c
xxx@x 01 +
XXX
+002c
002b
xxx@x 01 +
XXX
+002b
002a
xxx@x 01 +
Bug in git rebase --continue in v1.8.4
Hi, if I run rebase --continue (e.g. after a conflict resolution), then the rebase always ends with this error message: It seems that there is already a rebase-apply directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr /home/tron/gitRebaseTest/test/.git/rebase-apply and run me again. I am stopping in case you still have something valuable there. This happens on git v1.8.4 on FreeBSD. It is fine with v1.8.3.4. It seems to be caused by a1549e1049439386b9fd643fae236ad3ba649650, specifically this hunk: --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -7,12 +7,12 @@ case $action in continue) git am --resolved --resolvemsg=$resolvemsg move_to_original_branch - exit + return ;; skip) git am --skip --resolvemsg=$resolvemsg Attached is a test script for this problem. Regards Christoph #! /bin/sh set -eux git init test cd test echo a file git add . git commit -m a git branch -t test echo b file git add . git commit -m b git checkout test echo c file git add . git commit -m c ! git rebase git checkout --theirs . git add . git rebase --continue
