Am 09.08.2017 um 19:39 schrieb Yaroslav Halchenko:
> More context (may be different issue(s)) could be found at
> http://git-annex.branchable.com/forum/git-annex_add_out_of_memory_error/
> but currently I am consistently reproducing it while running
> git (1:2.11.0-3 debian stretch build) within debian stretch singularity
> environment [1].
> 
> External system is Centos 6.9, and git 1.7.1 (and installed in modules
> 2.0.4) do not show similar buggy behavior.
> 
> NFS mounted partitions are bind mounted inside the sinularity space and
> when I try to do some git operations, I get that error inconsistently , e.g.
> 
>       yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin 
> master
>       fatal: Out of memory, getdelim failed
>       error: git://github.com/datalad/datalad did not send all necessary 
> objects
> 
>       yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin 
> master
>       fatal: Out of memory, getdelim failed
>       error: git://github.com/datalad/datalad did not send all necessary 
> objects
> 
>       yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin 
> master
>       From git://github.com/datalad/datalad
>        * branch              master     -> FETCH_HEAD
>       fatal: Out of memory, getdelim failed
> 
> and some times it succeeds.  So it smells that some race condition
> somewhere...?

I doubt the type of file system matters.  The questions are: How much
main memory do you have, what is git trying to cram into it, is there
a way to reduce the memory footprint or do you need to add more RAM?

> any recommendations on how to pin point the "offender"? ;)
Running "GIT_TRACE=1 git pull --ff-only origin master" would be a
good start, I think, to find out which of the different activities
that pull is doing causes the out-of-memory error.

"free" and "ulimit -a" can help you find out how much memory you can
use.

Also: What does "wc -L .git/FETCH_HEAD .git/packed-refs" report?
getdelim() is used mostly to read lines from files like these and in
the admittedly unlikely case that they are *really* long such an
error would be expected.

René

Reply via email to