<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.
