Re: t5800-*.sh: Intermittent test failures

From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Sep 8, 2011, 17:42 UTC
Message-ID: <4E68FE73.4000005@ramsay1.demon.co.uk>
In-Reply-To: <7vpqjgyvn1.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 18 quoted lines

> Sverre Rabbelier <srabbelier@gmail.com> writes:
>> On Tue, Aug 9, 2011 at 20:30, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>>> The git-fast-import is hung in the read() syscall waiting for data which will
>>> never arrive. This is because the git(fast-export) process, started by the above
>>> git(push), executes (producing it's data on stdout) and completes successfully
>>> and exits *before* the above git-fast-import process starts.
>>>
>>> I haven't looked to see how the git(fast-export)/git-fast-import processes are
>>> plumbed together, but there seems to be a synchronization problem somewhere ...
>> This seems odd, before the fast-export process is even started it's
>> stdout are wired to the stdin of the helper (and thus the fast-import
>> process). What indication do you have that fast-import hasn't started
>> and that fast-export has finished?
>>
>> Also, you say git remote-test everywhere, but it should be git
>> remote-testgit, typo?
> 
> FWIW, I have been seeing this every once in a while.

Good to know I'm not alone ;-P

Unfortunately, I haven't had the time to debug this further than I've already reported ...

As I said, it's obviously a process plumbing/synchronization problem; the reading end of the fast-export output pipe must be open for read by someone (probably by it's parent), otherwise it would receive SIGPIPE (also, the output is small enough not to fill the pipe) rather than exiting with success.

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.

Well, ... I added debug code to git-fast-{im,ex}port which writes the debug info to a file (can't write to stdout/stderr obviously), so that may well be affecting the timing enough to increase the chance of a failure. Having said that, If I'm listening to music (rhythmbox) at the same time, then the failure rate seems to increase ...

ATB, Ramsay Jones