git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Larkin <nobrow@eircom.net>
To: unlisted-recipients:; (no To-header on input)
Cc: git@vger.kernel.org
Subject: Re: fatal: Out of memory, malloc failed
Date: Sun, 15 Apr 2007 20:06:53 +0100	[thread overview]
Message-ID: <462277CD.5020609@eircom.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0704131143130.28042@woody.linux-foundation.org>

Linus Torvalds wrote:
> 
> On Fri, 13 Apr 2007, Alan Larkin wrote:
>> Its not a huge push Im trying to do here (<about 150Mb) but always malloc fails!
> 
> Any huge objects?
> 
> Also, it might be interesting to run it under gdb, and put a breakpoint on 
> the "die" function, so that it stops where it runs out of memory. Then. at 
> that point, you can:
> 
>  - do a "where" in gdb to see what allocation it is (and ask it how big 
>    it was by printing out the value of "size").
> 
>    It may be something totally uninteresting (just some random object that 
>    happened to push things over the limit), but statistically, malloc 
>    failures tend to happen to big objects, and sometimes just because 
>    somebody needed a huge area that won't fit in the virtual address 
>    space.
> 
>  - check with "ps" what the size of the process is. Maybe you even just 
>    have some process limit set that causes brk/mmap to return failure 
>    earlier than necessary..
> 
>    (It can also be interesting to look at /proc/<pid>/maps, in case
>    there are big mmaps that fill up the VM etc)
> 
> Sometimes it's also a good idea to have a swap file.  You may not even
> *need* to actually page, but it gives thew VM layer much more freedom,
> especially if your distro has set the flags to disable memory "overcommit".
> 
> 		Linus
> 
> 

There were a couple of big files. I removed a 72Mb one (making 47Mb the biggest one left in the
project) and made the push and it worked. I later pulled the project down to a different machine,
added the 72Mb file back in, and pushed to the server and it worked. So apparently it's a platform
specific problem. If anybody's particularly interested I could replicate it under gdb and pass on
any info, but if not I wont ... job's done, Im happy.

  reply	other threads:[~2007-04-15 19:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-13 17:25 fatal: Out of memory, malloc failed Alan Larkin
2007-04-13 18:53 ` Linus Torvalds
2007-04-15 19:06   ` Alan Larkin [this message]
2007-04-15 21:40     ` Alex Riesen
2007-04-16  7:46       ` Alan Larkin
2007-04-16  7:54         ` Julian Phillips
2007-04-16  8:02           ` Alan Larkin
2007-04-16  8:03           ` Alex Riesen
2007-04-16  8:00         ` Alex Riesen
2007-04-16  8:11           ` Alan Larkin
2007-04-16  9:21             ` Alex Riesen

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=462277CD.5020609@eircom.net \
    --to=nobrow@eircom.net \
    --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).