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

[Erik Faye-Lund <kusmabite@googlemail.com>]

On Sat, Feb 6, 2010 at 11:06 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> 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