Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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