47

git pull fails with following error

remote: Counting objects: 146, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

Any Ideas how to pull successfully ?

deimus
  • 9,565
  • 12
  • 63
  • 107

4 Answers4

64

The lines beginning with remote are output from git running on the remote system. The error:

fatal: unable to create thread: Resource temporarily unavailable

... strongly suggests that you've run out of memory on the server, which can happen if you have either:

  1. A repository with lots of large files, which can cause re-packing to take a lot of memory.
  2. Limited virtual memory - either in general, or just for that account due to the ulimit setting

A suggestion here is to limit the amount of memory that packing may take by logging into the remote system (as the user that git runs as) and doing:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"
Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • 1
    Thank you! I was receiving the same error as OP. I tried implementing pack.windowMemory and pack.SizeLimit config items, but I was still receiving the error. When I added pack.threads "1" everything was resolved! – Brian C Jan 24 '13 at 21:37
  • 4
    I started with great enthusiasm when I tried to switch from svn to git. But running from one obscure problem to problem whose fix is even more obscure, I am not sure how wise the decision was for the switch. – René Nyffenegger Mar 21 '14 at 16:42
  • I had a problem with that I change property pack.SizeLimit instead of pack.packSizeLimit. This solved my problem. Thank you very much!!! – Stargazer Jun 09 '16 at 08:45
  • `git config --global pack.windowMemory "100m"` fixed my problem – Shadrack Kibet Oct 18 '20 at 18:26
11

Complementing the @Mark Longair's answer:

I had to run the following commands to fix this issue:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 
git config --global pack.deltaCacheSize "512m"

You can see more about these commands in the git documentation git config.

Wesley Gonçalves
  • 1,985
  • 2
  • 19
  • 22
  • what are the default values of these parameters ? – RichWalt Jun 18 '22 at 02:34
  • According to the documentation page I mentioned above, the default value of `packSizeLimit` is *unlimited* and `pack.deltaCacheSize` is 256 MiB. `pack.threads` is not mentioned, but it's probably *auto detection* (same as zero). But if you want to set them to default, you can simply delete them from the global config file. – Wesley Gonçalves Jun 18 '22 at 15:46
2

Warning: if you see this error with Git 2.19.1, this is expected, and documented in git-for-windows/git issue 1839: "git gc crashes at 33% of counting objects" (which reports an APPCRASH both for git gc, but also for git pull), because of a mutex used in "git pack-objects", which was not correctly initialized and caused "git repack" to dump core on Windows.

As mentioned in the issue:

It affects more than just gc. I hit a variant of it with pull too:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

This is fixed in Git 2.20 (Q4 2018).
See commit 34204c8, commit 9308f45, commit ce498e0 (16 Oct 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 620b00e, 30 Oct 2018)

pack-objects (mingw): initialize packing_data mutex in the correct spot

In 9ac3f0e (pack-objects: fix performance issues on packing large deltas, 2018-07-22, Git v2.19.0-rc1), a mutex was introduced that is used to guard the call to set the delta size. This commit even added code to initialize it, but at an incorrect spot: in init_threaded_search(), while the call to oe_set_delta_size() (and hence to packing_data_lock()) can happen in the call chain check_object() <- get_object_details() <- prepare_pack() <- cmd_pack_objects(), which is long before the prepare_pack() function calls ll_find_deltas() (which initializes the threaded search).

Another tell-tale that the mutex was initialized in an incorrect spot is that the function to initialize it lives in builtin/, while the code that uses the mutex is defined in a libgit.a header file.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • One can check the [size of those `object_entry`](https://stackoverflow.com/a/61550028/6309) – VonC Jul 14 '22 at 05:00
1

I was able to resolve this using following steps

Step 1. clone using lesser depth

git clone https://your_git_clone_url --depth 3

Step 2. Edit .git/config and add line for develop. This is required as after setting depth I was not able to switch remote branch other than master

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
[remote "origin"]
    url = https:<your git clone url>
    fetch = +refs/heads/master:refs/remotes/origin/master
    fetch = +refs/heads/develop:refs/remotes/origin/develop  <<--- Add this line
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "develop"]
    remote = origin
    merge = refs/heads/develop

Step 3: get fetch

prashant patankar
  • 51
  • 5