RE: Unable to commit 150MB text design file (out of memory)

[Bulgrien, Kevin]

<snip>

> Yes, the client is running on Microsoft Windows XP SP2 under an MSYS
> environment.  MinGW is not installed, only MSYS.  The exact version
> reported by cvs.exe --version is
> 
>   Concurrent Versions System (CVS) 1.11 (client/server)
> 
> Moving the cvs.exe over to a real Linux system, I can strings 
> cvs.exe |
> grep cvs and get:
> 
>   ../../../src/cvs-1.11.0/src/main.c
> 
> So it appears to be cvs 1.11.0.
> 
> > >   cvs [remove aborted]: out of memory
> > >   cvs [commit aborted]: out of memory
> > >   cvs [update aborted]: out of memory
> > 
> > If you are running ms windows then the problem may be a bug in the
> > Microsoft C runtime library.  If you reallocate a memory 
> block enough
> > times then eventually MSVCRT claims it is out of memory when in fact
> > there is still plenty available.  It's been a bug for years 
> > now.  We've
> > shipped patches of CVSNT to customers with support that 
> > either uses the
> > native windows memory alloction calls or simply allocates the 
> > memory in
> > large 'chunks' to get around the issue.  The current FOSS builds of
> > CVSNT don't have this patch since we are still evaluating the 
> > success of
> > it.
> 
> Dependency Walker shows it to only depend on KERNEL32.dll and
> msys-1.0.dll and indirectly on NTDLL.DLL.
 
<snip>

> > Of course if you've compiled with Ming then it may be using 
> its own C
> > run time which may have the same or a different problem or it 
> > could just be a known bug in the (unknown) version of 1.11 you are
> > using.
> 
> I didn't compile it but rather took it straight from the MSYS-DTK
> installer built in 2004.  It has worked nicely being an .exe installer
> for almost-idiotproof installs, but it looks like I really ought to
> look into using a newer snapshot release.
> 
> I see that MSYS has have sources and binary tarballs for cvs-1.11.22
> on SourceForge.  They will easier to try than setting up a new server.
> A newer snapshot is almost certain to have these versions packaged in
> with it.

To perhaps bring a measure of closure to this thread:

Turns out it is the client as moving the file to the server and doing
the operation from there works, but initial attempts with the latest
msys-1.0.dll and cvs.exe (cvs-1.11.22) on the client system do not
seem to correct the issue.  Completely updating MSYS also does not
cure the issue either, so it looks like fixing it may require Windows
work... adding RAM, or whatever... just bumping up the page file
size did not help.

We also should have tried `cvs -t` as this gives some additional
information about where the error occurs:

 -> Sending file '...' to server 

Not that it made any sense to do so, but we added -z3 to the CVS
command.  That resulted in a more spectacular crash (a Windows error
report after the out of memory condition occurs).  Tying back in to
Arthur's comment, it is interesting to note that mscvrt.dll is
mentioned in this report.

Thanks all for your comments that at least helped me to get to this
point.  I have no real idea how to troubleshoot Windows XP memory
issues so at least I have a workaround.  One could try various
clients... but at some point that gets counter-productive for
infrequent issue.

---
Kevin R. Bulgrien
Design and Development Engineer

This email message is for the sole use of the intended recipient(s) and may 
contain General Dynamics SATCOM Technologies confidential or privileged 
information.  Any unauthorized review, use, disclosure or distribution is 
prohibited.  If you are not an intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.