possible race condition (fetch-pack: unexpected disconnect while reading sideband packet)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I'd like to report a bug, if it's not already known, but I wasn't able to find it on https://lore.kernel.org/git/.

Setup:
We use Git for Windows in version 2.31.0 on MS Windows Server 2019, to access repository on Gitlab 13.10. Both machines are virtual under different physical machines, but still in the same server room connected with high speed network to each other.

Reproducibility:
random (like 50:50)

Reproducer:
Try to clone (initial clone, or initial init && fetch, doesn't matter) a repo from the gitlab to the machine

Expected results:
Repository cloned/fetched successfully


Actual result (when failed):
Cloning into 'local-repo-name'...
remote: Enumerating objects: 237, done.
remote: Counting objects: 100% (237/237), done.
remote: Compressing objects: 100% (129/129), done.
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Notes:
Some repositories are almost always successful (doesn't matter if they are bigger or smaller), clone and init+fetch seem to behave similarly (from the perspective of the issue). From any machine on the same network, but e.g. through several network routers or VPN, the issue was never observed.
Our current git config:
C:\Users\username>git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=schannel
core.autocrlf=true
core.fscache=true
core.symlinks=false
core.editor=notepad
pull.rebase=false
credential.helper=manager-core
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
http.postbuffer=512000000*
core.compression=9*
core.packedgitlimit=512m*
core.packedgitwindowsize=512m*
pack.deltacachesize=2047m*
pack.packsizelimit=2047m*
pack.windowmemory=2047m*
sendpack.sideband=false*

These marked with asterisk(*) were added to localize this issue, without any observable effect.

I'm willing to provide more information or even contribute on the fix, just let me know what should I do/try. Thank you.

Best Regards,
Martin Simon



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux