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

On Sat, Feb 6, 2010 at 11:06 AM, Johannes Sixt [off-list ref] wrote:

On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:

quoted

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