Re: git checkout crashes after server being updated to Debian X86_64

From: Raffael Reichelt <raffael.reichelt@gmail.com>
Date: Oct 18, 2016, 17:00 UTC
Message-ID: <CE31577A-2172-402B-90AF-683283D26B2D@gmail.com>
In-Reply-To: <1c70da04-d26b-f0af-8939-edc96de586d9@web.de>

Hello Renè! file is returning

/usr/bin/git: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,  BuildID[sha1]=ee62e538d6fe6673d3ba49f0e66bfec784cc32bc, stripped

and ulimit is: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 1 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 512 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) 1800 max user processes (-u) 42 virtual memory (kbytes, -v) 786432 file locks (-x) unlimited

Support told me git is limited to 600M

Regrads, Rafael

Show 66 quoted lines

> Am 18.10.2016 um 18:42 schrieb René Scharfe <l.s.r@web.de>:
> 
> Am 18.10.2016 um 17:17 schrieb Raffael Reichelt:
>> Hello!
>> 
>> I have a serious problem with git, After my provider had updated to a
>> X86_64 architecture git crashes with various memory-related errors.
>> This is happening remote when pushing to the repository from my local
>> machine as well as trying it on a shell on the server itself.
>> 
>> This are the error-messages:
>> 
>> fatal: Out of memory, realloc failed
>> fatal: recursion detected in die handler
>> fatal: recursion detected in die handler
>> 
>> or
>> fatal: unable to create threaded lstat
>> fatal: recursion detected in die handler
>> or
>> fatal: unable to create threaded lstat
>> *** Error in `git': double free or corruption (fasttop): 0x0000000000a8ade0 ***
>> fatal: recursion detected in die handler
>> Aborted
>> 
>> It’s obviously not a problem of the repository - happens with all of
>> them. I think it is also not a question of size - happens with a 80M
>> Repository as well as with a 500M one.
>> 
>> Any way: did a
>> 
>> git fsck
>> Prüfe Objekt-Verzeichnisse: 100% (256/256), Fertig.
>> Prüfe Objekte: 100% (56305/56305), Fertig.
>> 
>> git gc --auto --prune=today —aggressive
>> git repack
>> 
>> Additionally I played around some config parameters  so my config now looks like:
>> [http]
>>    postbuffer = 524288000
>> [pack]
>>    threads = 1
>>    deltaCacheSize = 128m
>>    packSizeLimit = 128m
>>    windowMemory = 128m
>> [core]
>>    packedGitLimit = 128m
>>    packedGitWindowSize = 128m
>>    repositoryformatversion = 0
>>    filemode = true
>>    bare = true
>> 
>> I am running
>> git version 2.1.4
>> 
>> on
>> Linux infongp-de65 3.14.0-ui16196-uiabi1-infong-amd64 #1 SMP Debian 3.14.73-2~ui80+4 (2016-07-13) x86_64 GNU/Linux
>> 
>> Anyone out there to help me getting out of this trouble?
> 
> Git 2.1.4 is the version that comes with Debian stable according to https://packages.debian.org/jessie/git, so I guess using a more recent version is not a reasonable option.
> 
> What do "file $(which git)" and "ulimit -a" return?  Do you have an x86-64 binary and no unnecessarily low limits set?
> 
> René