Jeff King wrote:
> On Thu, Sep 08, 2011 at 06:42:11PM +0100, Ramsay Jones wrote:
>
>> When I run the tests with "make test >test-out", I see a failure rate of about
>> 1 in 10. If I then set the debug environment variables (GIT_TRANSPORT_HELPER_DEBUG,
>> GIT_TRANSLOOP_DEBUG and GIT_DEBUG_TESTGIT) and run the test script directly (-v),
>> then the failure rate goes up to about 1 in 3.
>
> Hmm. I can't reproduce a failure here, but I do get some weirdness. My
> recipe is:
Ah, sorry, ... I didn't make myself clear then, because ...
> -- >8 --
> cat >foo.sh <<\EOF
> #!/bin/sh
>
> exec >$1.out 2>&1
>
> n=0
> while test $n -lt 100; do
> n=$(($n+1))
> GIT_TRANSPORT_HELPER_DEBUG=1 \
> GIT_TRANSLOOP_DEBUG=1 \
> GIT_DEBUG_TESTGIT=1 \
> ./t5800-remote-helpers.sh --root=/run/shm/git-tests-$1 -v || {
> echo FAIL $n
> exit 1
> }
> echo OK $n
> done
> EOF
>
> # try to keep an 8-core machine busy
> for i in `seq 1 16`; do
> sh foo.sh $i &
> done
> -- 8< --
>
> I never see a test failure, but a few of the 16 end up hanging. The
> process tree for the hanged tests look like:
>
> t5800-remote-helper
> git push
> git-remote-testgit
> git fast-import
> git-fast-import
>
> All of them are blocked on wait(), except for the final fast-import,
> which is blocked trying to read() from stdin.
... these hangs *are* the failures of which I speak! Yes, the script
doesn't get to declare a failure, but AFAIAC a hanging test (and it
isn't the same test # each time) is a failing test. :-D
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html