Re: [msysGit] upload-pack timing issue on windows?

From: Erik Faye-Lund <kusmabite@googlemail.com>
Date: Feb 6, 2010, 12:01 UTC
Message-ID: <40aa078e1002060401r1dec3c2ate3ddd4f5f5db1e0c@mail.gmail.com>
In-Reply-To: <201002061106.04305.j6t@kdbg.org>

On Sat, Feb 6, 2010 at 11:06 AM, Johannes Sixt <j6t@kdbg.org> wrote:

Show 20 quoted lines

> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:
>> As some of you might know, I've been working on porting git-daemon to
>> Windows for quite some time now. As it stands now, there's really only
>> one known issue that is blocking on my end here:
>>
>> Something weird happens *sometimes* when upload-pack is exiting,
>> leading to a client dying with a "fatal: read error: Invalid
>> argument\nfatal: early EOF"-error. If I place a sleep(1) at some place
>> after exiting the while(1)-loop in create_pack() in upload-pack.c, the
>> symptom goes away. create_pack() contains some async-code, but this
>> doesn't seem to be triggered in my minimal case at all. I've tried
>> flushing stdout and stderr explicitly, no luck.
>
> I've observed timing related issues in upload-pack as well, but only in the
> case where the die() is called from the async thread. This is the reason why
> t5530 does not pass.
>
> But your case seems to be different - i.e. there is no die() involved. Sorry,
> can't help more...
>

Yeah, it's probably not the same case, but I certainly do find it interesting that we seemingly have two separate timing-related around here somewhere...

> Perhaps use Procmon to analyse differences among the different successful and
> failing cases.
>

I'm not entirely sure what to look for, but I do see that there's difference. There's about 3.5k lines of logging from git.exe, git-daemon.exe and git-upload-pack.exe for the failure case versus 2.5k for the successful case. And the last sequence of TCP Send in the success case is a send of 8 bytes, followed by a send of 212 bytes, followed again by a send of 1 byte. In the failure case, there's only a send of 8 bytes in the end. This sequence is reported as sent by git-daemon.exe. In fact, all TCP actions are reported from git-daemon.exe, and apart from the last sequence the lengths are reported as identical.

> Try hacking fetch-pack so that it does not announce side-band(-64k). Perhaps
> it makes a difference.
>

This didn't make any difference. I removed "side-band" and "side-band-64k" from capabilities in send_ref() in upload-pack.c, as well as the "if (server_supports("side-band<...>"-lines in builtin-fetch-pack.c.

While I was at it, I also tried to disable all other capabilities; no luck.

However, I have tracked down a bit of what goes on in the client. There's a call to read_in_full, called from pack-write.c, line 246 that fails in the failure-case, but not in the success-case. This is where the client expects "pack\tSHA-1" or "keep\tSHA-1". There "fatal: early EOF"-messages seems to originate from index-pack.c, line 197. This is the first line of code in parse_pack_header(), it's also AFAICT the first call-site for any read(0, <...>) (though fill()).

-- 
Erik "kusma" Faye-Lund