test suite failure t5570, 8 with v2.4.1-168-g1ea28e1

Hi,

so today I am running make test (no special flags I am aware of) on my ubuntu machine using git v2.4.1-168-g1ea28e1 and t5570-git-daemon.sh (not ok 8 - fetch notices corrupt idx) fails.

Any hints?

Thanks, Stefan

On Tue, May 19, 2015 at 10:20 AM, Stefan Beller <sbeller@google.com> wrote:

It seems to be a flaky test. When I try the test with -d or -i it passes. Using -v it still fails,

test_must_fail: command succeeded: git --bare fetch git://127.0.0.1:5570/repo_bad2.git

On Tue, May 19, 2015 at 10:20:04AM -0700, Stefan Beller wrote:

It works for me. :)

Is the problem reproducible, or intermittent? The daemon-oriented tests sometimes can suffer from weird races.

If it is reproducible, what does running it with "-v -i" (and maybe "-x") say?

-Peff

On Tue, May 19, 2015 at 10:22 AM, Jeff King <peff@peff.net> wrote:

-x also keeps it failing

expecting success: cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git && (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git && p=`ls objects/pack/pack-*.idx` && chmod u+w $p && printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc ) && mkdir repo_bad2.git && (cd repo_bad2.git && git --bare init && test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad2.git" && test 0 = `ls objects/pack | wc -l` )

++ cp -R '/usr/local/google/home/sbeller/OSS/git/t/trash
directory.t5570-git-daemon/repo/repo_pack.git'
'/usr/local/google/home/sbeller/OSS/git/t/trash
directory.t5570-git-daemon/repo/repo_bad2.git'
++ cd '/usr/local/google/home/sbeller/OSS/git/t/trash
directory.t5570-git-daemon/repo/repo_bad2.git'
+++ ls objects/pack/pack-0de42e9908e5d304b40de56c4ce788ce0ff4eff0.idx
++ p=objects/pack/pack-0de42e9908e5d304b40de56c4ce788ce0ff4eff0.idx
++ chmod u+w objects/pack/pack-0de42e9908e5d304b40de56c4ce788ce0ff4eff0.idx
++ printf %0256d 0
++ dd of=objects/pack/pack-0de42e9908e5d304b40de56c4ce788ce0ff4eff0.idx
bs=256 count=1 seek=1 conv=notrunc
1+0 records in
1+0 records out
256 bytes (256 B) copied, 0.000129681 s, 2.0 MB/s
++ mkdir repo_bad2.git
++ cd repo_bad2.git
++ git --bare init
Initialized empty Git repository in
/usr/local/google/home/sbeller/OSS/git/t/trash
directory.t5570-git-daemon/repo_bad2.git/
++ test_must_fail git --bare fetch git://127.0.0.1:5570/repo_bad2.git
++ git --bare fetch git://127.0.0.1:5570/repo_bad2.git
[18703] Connection from 127.0.0.1:39945
[18703] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[18703] Request upload-pack for '/repo_bad2.git'
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 6 (delta 0)
[18534] [18703] Disconnected
Unpacking objects: 100% (6/6), done.
From git://127.0.0.1:5570/repo_bad2
 * branch            HEAD       -> FETCH_HEAD
++ exit_code=0
++ test 0 = 0
++ echo 'test_must_fail: command succeeded: git --bare fetch
git://127.0.0.1:5570/repo_bad2.git'
test_must_fail: command succeeded: git --bare fetch
git://127.0.0.1:5570/repo_bad2.git
++ return 1
error: last command exited with $?=1
not ok 8 - fetch notices corrupt idx
#
# cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git
"$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
# (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
# p=`ls objects/pack/pack-*.idx` &&
# chmod u+w $p &&
# printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
# ) &&
# mkdir repo_bad2.git &&
# (cd repo_bad2.git &&
# git --bare init &&
# test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad2.git" &&
# test 0 = `ls objects/pack | wc -l`
# )
#

$ git bisect bad
383c3427afa3201eb05e931825c5c2f20616b58b is the first bad commit
commit 383c3427afa3201eb05e931825c5c2f20616b58b
Author: Eric Sunshine <sunshine@sunshineco.com>
Date:   Mon May 4 03:25:14 2015 -0400

    t1007: add hash-object --literally tests

    git-hash-object learned a --literally option in 5ba9a93
    (hash-object: add --literally option, 2014-09-11). Check that
    --literally allows object creation with a bogus type, with two
    type strings whose length is reasonably short and very long.

    Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

On Tue, May 19, 2015 at 10:31 AM, Stefan Beller <sbeller@google.com> wrote:

When looking at the commit I don't think I found the right one. So I went back to HEAD^ (being v2.1.0-243-g0c3db67), which also tests bad now. Is there a way to force git bisect to change good to bad?

Sorry for the noise, it must be a machine specific thing at my end, because v2.3 and even v2.0.0 fail the test now.

To observe the failing test I run

    $ make && (cd t; ./t5570-git-daemon.sh)

which should be sufficient to not have stale data?

I'll try to follow the test script and look into the test details to actually understand what the problem is here.

And here comes the resolution of the puzzle. Remember when I claimed there are no special flags set in the first mail? Except one flag that is actually true. ;)

I did have a special flag set, which is CC = /usr/lib/gcc-snapshot/bin/gcc which is using the latest snapshot of the gcc compiler gcc (Ubuntu 20140405-0ubuntu1) 4.9.0 20140405 (experimental) [trunk revision 209146] instead of the standard install gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 on my machine

Using the standard compiler git build ands tests t5570,8 just fine in various versions.

If I take the latest snapshot of gcc, I have a flakey behavior in Git versions ranging from current origin/master back to v2.0.0 (did not test further)

Could somebody try to reproduce the failing test using the latest gcc snapshot compiler?

On Tue, May 19, 2015 at 12:16:57PM -0700, Stefan Beller wrote:

I'm not sure 2014 counts as the "latest". :) My stock compiler is 4.9.2, and gcc-snapshot on Debian unstable is:

  gcc (Debian 20150516-1) 6.0.0 20150516 (experimental)
  [trunk revision 223239]

Both versions I listed above seem to work fine for me. Of course we can't definitively rule out git provoking undefined behavior in certain compiler versions, but short of more data, I'd say it's probably a gcc bug in 4.9.0 which has since been fixed.

-Peff