[cvsnt] out of memory; can not reallocate

[Michael Wojcik]

> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of bwhicks at aep.com
> Sent: Friday, 09 February, 2007 13:35
> 
> I am testing moving a cvsnt server from linux to windows. The linux
server 
> was cvsnt2.5.02.2099 on redhat ES3 and the windows box is 
> cvsnt2.5.03.2382. We have a particular module that is relatively big
(1.7 
> GB, 17574 files) and I get an error on checkout that says:
> 
> cvs [server aborted]: out of memory; can not reallocate 322961408
bytes
> 
> This happens on the windows server and not on the linux server. I've
read 
> about the RAM requirements and such that people run into, but the
linux 
> server has 4 gigs of ram and 8 gigs of swap and the windows server is
a VM 
> with 3.6 gigs of RAM and 7.5 Gigs of swap.

Forget RAM; the whole point of a paged-virtual-memory operating system
is that processes aren't constrained by physical memory.

We can't evaluate whether swap space is a problem without knowing the
total demand on virtual memory on the server, but it's very unlikely.

The important differences are in the C runtimes, which are completely
different implementations (presumably glibc of some vintage on Linux,
MSVC 7.1 on Windows), and therefore may have different
implementation-defined behaviors; and the OSes, from which the C runtime
must request memory, and which are radically different.

The realloc C library function can satisfy a reallocation request in two
ways: it can extend the existing area; or it can allocate a new area and
copy the data from the old area, then free the old one.  Whether
extending an area is possible depends on a host of factors, but C
library implementation and OS figure prominently.  So it may well be
that on Linux, CVS is able to resize the area, but on Windows it needs
to allocate fresh and copy, which means it might actually need
considerably more than the amount it's trying to allocate, at least
ephemerally.

322961408 bytes is about 308 MB, which is a sizable chunk of available
address space in a 32-bit process model.  32-bit Windows reserves big
portions of the process address space for stack, shared libraries, etc.
That leaves only so much for the heap (where dynamically-allocated
memory comes from); at the point where this reallocation request occurs,
there may simply not be 308 MB of address space left for the heap to
grow into.

I've never had to alleviate heap-space exhaustion for a Windows
application, so I'm not sure what your options are here.  (Other than
not putting 308 MB files into CVS, of course - and it's probably rather
too late for that.)  But maybe these suggestions will help you research
possible solutions.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus