Why does Git.pm on cygwin complain about 'Out of memory during "large" request?

Question

I'm getting this error while doing a git svn rebase in cygwin

Out of memory during "large" request for 268439552 bytes, total sbrk() is 140652544 bytes at /usr/lib/perl5/site_perl/Git.pm line 898, <GEN1> line 3.

268439552 is 256MB. Cygwin's maxium memory size is set to 1024MB so I'm guessing that it has a different maximum memory size for perl?

How can I increase the maximum memory size that perl programs can use?

update: This is where the error occurs (in Git.pm):

 while (1) {
      my $bytesLeft = $size - $bytesRead;
      last unless $bytesLeft;

      my $bytesToRead = $bytesLeft < 1024 ? $bytesLeft : 1024;
      my $read = read($in, $blob, $bytesToRead, $bytesRead); //line 898
      unless (defined($read)) {
         $self->_close_cat_blob();
         throw Error::Simple("in pipe went bad");
      }

      $bytesRead += $read;
   }

I've added a print before line 898 to print out $bytesToRead and $bytesRead and the result was 1024 for $bytesToRead, and 134220800 for $bytesRead, so it's reading 1024 bytes at a time and it has already read 128MB. Perl's 'read' function must be out of memory and is trying to request for double it's memory size...is there a way to specify how much memory to request? or is that implementation dependent?

UPDATE2: While testing memory allocation in cygwin: This C program's output was 1536MB

int main() {
   unsigned int bit=0x40000000, sum=0;
   char *x;

   while (bit > 4096) {
      x = malloc(bit);
      if (x)
         sum += bit;
      bit >>= 1;
   }
   printf("%08x bytes (%.1fMb)\n", sum, sum/1024.0/1024.0);
   return 0;
}

While this perl program crashed if the file size is greater than 384MB (but succeeded if the file size was less).

open(F, "<400") or die("can't read\n");
$size = -s "400";

$read = read(F, $s, $size);

The error is similar

Out of memory during "large" request for 536875008 bytes, total sbrk() is 217088 bytes at mem.pl line 6.

Answer 1

This is a problem that has been solved in the latest version of msysgit by Gregor Uhlenheuer. There is a patch available. The problem is that in Git.pm, the file is read in one go. The solution is to read it in small chunks. I'm not sure if the fix has made it into any released versions, but the fix is easy to apply locally.

You need to change C:\Program Files\Git\lib\perl5\site_perl\Git.pm (about 8 lines change). Make sure you back it up first.

For the details of what to do, see Git.pm: Use stream-like writing in cat_blob().

The original discussion is Problems with larger files "Out of memory".

Answer 2

Have you tried increasing overall Cygwin's usable memory?

That message shows Perl was already up to 130 MiB (total sbrk()) and then tried to request a further 256MiB which failed.

From http://www.perlmonks.org/?node_id=541750

By default no Cygwin program can allocate more than 384 MB of memory 
(program+data). You should not need to change this default in most 
circumstances. However, if you need to use more real or virtual 
memory in your machine you may add an entry in the either the 
HKEY_LOCAL_MACHINE (to change the limit for all users) or
HKEY_CURRENT_USER (for just the current user) section of the registry.

Add the DWORD value heap_chunk_in_mb and set it to the desired 
memory limit in decimal MB. It is preferred to do this in Cygwin 
using the regtool program included in the Cygwin package. (For 
more information about regtool or the other Cygwin utilities, 
see the Section called Cygwin Utilities in Chapter 3 or use 
each the --help option of each util.) You should always be 
careful when using regtool since damaging your system registry
can result in an unusable system. 

Answer 3

This is not a Perl-specific issue, but rather one related to cygwin. You can raise memory allocation with ulimit.

What version of git are you using? If you're not on the latest version, this might be an inefficiency that has been fixed with the latest version (e.g. looping through a very large file with foreach rather than while, as google suggests when I did a quick search.)