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?

[dscho]

@linquize ping?

[linquize]

Not easy to give out MCVE. But it happens quite often every day.

[dscho]

Nevertheless, if this ticket should have any hope of getting addressed, ever, we need a reliable way to reproduce the issue, if only to verify that it is fixed (when it is fixed).

[dscho]

I finally could reproduce the error, although it took 74 (!!!) attempts to get there. This is not reproducible enough, unfortunately, because when I have a tentative fix I need a definitive answer to the question whether it actually fixes the bug.

[shiftkey]

Closing this one out as stale. Please comment if anyone is actively using the git daemon server and willing to help reproduce this consistently.

[linquize]

I haven't use git daemon for a long time because of this unresolved issue and it is hard to report an MCVE.
In the mean time, I use jgit daemon instead.

[multiplemonomials]

I'm using the git daemon, and I get this error every single time. Pulling from one Windows 10 PC to another. Both are using git 2.6.3.windows.1. Interestingly, I can successfully pull from PC#1 to PC#2 when PC#2 is booted into Linux, but it displays an error at the end.

[Kagami]

Experience this issue on Windows 7 with latest Git 2.12.0. Basically I can't not to reproduce, I always get Connection reset by peer error. Windows is 64bit and inside VirtualBox VM, trying to git fetch from Linux host if that matters.

[cmaslen]

I also get this issue pretty much every time cloning to a remote Windows machine. Cloning to my local machine to say a different directory never has the issue using a different Git Bash window.

This Stack Overflow answer helped me out. I don't need this to be ultra reliable, but it's handy if you want do a peer merge or share a non hosted repo.

https://stackoverflow.com/a/41779686/450100

It's odd behaviour, but perhaps it might make sense to the developers.

[linquize]

On the client side, I have to run below command until fetch successful (may be more than 10 times)
while true; do git fetch git://192.168.1.123/; done