git-for-windows git daemon server makes client early EOF error

[linquize]

git-for-windows git daemon server (on Windows) makes client (any platform) early EOF error
Such problem already exist in msysgit pre 2.0 versions.

The problem still exists in git-for-windows 2.x.

fatal: read error: Invalid argument
fatal: early EOF
fatal: index-pack failed

[dscho]

I guess this is the very same issue as msysgit#70 tries to address. I have to guess because the report is unfortunately nowhere near the Minimal, Complete and Verifiable Examples for which I always ask.

@linquize please provide such an MCVE.

[linquize]

Yes, exactly the same as msysgit#70, because I could not search that issue by keyword.

[dscho]

Okay, now that we established that you have the same problem as reported elsewhere, but also that the discussion there was not able to tell me what is wrong, and therefore was not able to convince me that the fix was correct (or for that matter, minimally intrusive), how about stepping up the game a little bit. You need a fix, and I can help you come up with one.

Step 1: reduce your workflow to a Minimal, Complete and Verifiable Example.

This is essential. Without this, we cannot hope to investigate this problem efficiently because I, for one, have not been able to reproduce it. And if I cannot reproduce it, I cannot verify any fix, either.

Step 2: from that minimal example, figure out the culprit.

This is essentially a tedious, but necessary process to test hypotheses where the state or the flow is different from the expected one.

Step 3: come up with a fix.

This is where I can help because I know the code base as well as Git for Windows' architecture pretty well.

Step 4: incorporate, test, and release.

This is the dessert.

[linquize]

1. On PC 192.168.1.1 (Win 7 x64), git clone git://github.com/gitster/git.git
2. cd git
3. git daemon --verbose --export-all --base-path=.
4. On another PC / VM (any platform), git clone git://192.168.1.1/

Cloning into 'C:\192.168.1.1'...
remote: Counting objects: 179838, done.
remote: Compressing objects:  65% (30010/4Receiving objects:   0% fatal: early EOF
remote: Compressing objects: 100% (46169/46169), done.
fatal: read error: Invalid argument
fatal: index-pack failed

[elieux]

If it's any help, I can't reproduce with 1.9.5.msysgit.1. I tried with a Windows client (same system as the daemon, but data went over network) and a Linux client (in a VM).

[linquize]

@elieux Run clone / fetch many times, not just one or two times

[dscho]

@linquize does this really require two PCs? That is not really "minimal"... I would have to buy another computer to reproduce the problem you described. Is there really no way to reproduce on one machine?

[elieux]

@dscho, to be fair, they did say "PC / VM".

[elieux]

So after around 10 (or 30) clones on a Linux VM, I started randomly getting this on the client:

Cloning into 'clone12'...
remote: Counting objects: 178307, done.
remote: Compressing objects: 100% (45869/45869), done.
fatal: read error: Connection reset by peer.63 MiB | 17.54 MiB/s
Receiving objects: 100% (178307/178307), 56.56 MiB | 17.54 MiB/s, done.
Resolving delts: 100% (130544/130544), done.
fatal: error in sideband demultiplexer

I don't know if it's relevant to this issue or if it's even a fatal error (everything's at 100 percent). I can dig deeper if desired.

The uncertainty in the number of tries needed to reproduce this problem comes from the fact that I don't know if it's only about random chance, or I should account for all the checkouts I did with the same daemon instance beforehand from another client.

[dscho]

@linquize please do try to make it easier to reproduce, so far you are the only one who can. From the msysGit issue, it looks as if you should be able to trigger the problem more reliably by inserting Sleep(1000); statements at specific locations in the client or the server.

[linquize]

Since this is a timing issue, it may also sometimes shows fatal: error in sideband demultiplexer,
sometimes shows fatal: early EOF

[dscho]

@linquize any progress with that MCVE?