Looking at http://msdn2.microsoft.com/en-us/library/ms810627.aspx it looks like (a) windows provides 2G of address space to play with (b) VirtualAlloc is constrained to allocating contiguous ranges of memory within that 2G address space So the problem is probably memory fragmentation. You might have more joy if you allocated one HUGE chunk immediately on startup to use for the pack, and then kept re-using that chunk. Alex Riesen wrote: > For me, it fails even on 332Mb pack: > > $ git reset --hard 61bb7fcb > fatal: packfile .git/objects/pack/pack-ad37...pack cannot be mapped. > > Instrumenting the code reveals that it fails on 348876870 bytes. > Strangely enough, a cygwin program which just reads that pack > many times without freeing the mem goes up to 1395507480 (1330Mb). > > If I replace the malloc (cygwin) with native VirtualAlloc(MEM_COMMIT) > it reports that "Not enough storage is available to process this > command", > which is just ENOMEM, I think. > > This is a 2Gb machine, with almost 1.3Gb free, so I'm a bit confused, > what could here go wrong (besides what already is wrong). > > Any ideas? > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > NOTICE: This email, and the contents thereof, are subject to the standard Peralex email disclaimer, which may be found at: http://www.peralex.com/disclaimer.html If you cannot access the disclaimer through the URL attached and you wish to receive a copy thereof please send an email to email@xxxxxxxxxxx