From: "Shawn O. Pearce" <spearce@spearce.org>
To: David Abrahams <dave@boostpro.com>
Cc: git@vger.kernel.org
Subject: Re: "malloc failed"
Date: Tue, 27 Jan 2009 07:29:16 -0800 [thread overview]
Message-ID: <20090127152915.GA1321@spearce.org> (raw)
In-Reply-To: <878wow7pth.fsf@mcbain.luannocracy.com>
David Abrahams <dave@boostpro.com> wrote:
> I've been abusing Git for a purpose it wasn't intended to serve:
> archiving a large number of files with many duplicates and
> near-duplicates. Every once in a while, when trying to do something
> really big, it tells me "malloc failed" and bails out (I think it's
> during "git add" but because of the way I issued the commands I can't
> tell: it could have been a commit or a gc). This is on a 64-bit linux
> machine with 8G of ram and plenty of swap space, so I'm surprised.
>
> Git is doing an amazing job at archiving and compressing all this stuff
> I'm putting in it, but I have to do it a wee bit at a time or it craps
> out. Bug?
No, not really. Above you said you are "abusing git for a purpose
it wasn't intended to serve"...
Git was never designed to handle many large binary blobs of data.
It was mostly designed for source code, where the majority of the
data stored in it is some form of text file written by a human.
By their very nature these files need to be relatively short (e.g.
under 1 MB each) as no human can sanely maintain a text file that
large without breaking it apart into different smaller files (like
the source code for an operating system kernel).
As a result of this approach, the git code assumes it can malloc()
at least two blocks large enough for each file: one of the fully
decompressed content, and another for the fully compressed content.
Try doing git add on a large file and its very likely malloc
will fail due to ulimit issues, or you just don't have enough
memory/address space to go around.
git gc likewise needs a good chunk of memory, but it shouldn't
usually report "malloc failed". Usually in git gc if a malloc fails
it prints a warning and degrades the quality of its data compression.
But there are critical bookkeeping data structures where we must be
able to malloc the memory, and if those fail because we've already
exhausted the heap early on, then yea, it can fail too.
--
Shawn.
next prev parent reply other threads:[~2009-01-27 15:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-27 15:04 "malloc failed" David Abrahams
2009-01-27 15:29 ` Shawn O. Pearce [this message]
2009-01-27 15:32 ` David Abrahams
2009-01-27 18:02 ` Johannes Schindelin
2009-01-28 5:02 ` Jeff King
2009-01-28 21:53 ` David Abrahams
2009-01-29 0:06 ` David Abrahams
2009-01-29 5:20 ` Jeff King
2009-01-29 5:56 ` Jeff King
2009-01-29 7:53 ` Junio C Hamano
2009-01-29 13:10 ` David Abrahams
2009-01-29 13:41 ` Andreas Ericsson
2009-01-30 4:49 ` Jeff King
2009-01-28 22:16 ` Pau Garcia i Quiles
2009-01-29 5:14 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090127152915.GA1321@spearce.org \
--to=spearce@spearce.org \
--cc=dave@boostpro.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).