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

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

[Stefan Beller]

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

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

[Stefan Beller]

On Tue, May 19, 2015 at 10:20 AM, Stefan Beller <sbeller@google.com> wrote:
> 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?

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

>
> Thanks,
> Stefan

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

[Jeff King]

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

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

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

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

[Stefan Beller]

On Tue, May 19, 2015 at 10:22 AM, Jeff King <peff@peff.net> wrote:
> On Tue, May 19, 2015 at 10:20:04AM -0700, Stefan Beller wrote:
>
>> 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?
>
> 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?

-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`
# )
#

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

[Stefan Beller]

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

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

[Stefan Beller]

On Tue, May 19, 2015 at 10:31 AM, Stefan Beller <sbeller@google.com> wrote:
> $ 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>

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?

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

[Stefan Beller]

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.

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

[Stefan Beller]

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?

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

[Jeff King]

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

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

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]

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

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