> -----Original Message----- > From: Arthur Barrett [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 12, 2008 2:55 PM > To: Bulgrien, Kevin; [email protected] > Subject: RE: Unable to commit 150MB text design file (out of memory) > > Kevin, > > > Using a 1.11 cvs client under MSYS > > Do you mean Microsoft Windows with MingW installed? > Which EXACT version of 1.11 are you running?
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. I guess I was considering that the google comments I read indicated that the out of memory probably was almost certainly server-side, but as I write that, it is quite obvious that almost is not the same as almost certainly. I really ought to scp that file down onto the server and try the operation from there. Thinking out loud, I am using a 20040430 installer instead of the most recent snapshot, and the msys-1.0.dll from that installer does also have some known issues (tar fails with large files) that are fixed by putting a newer msys-1.0.dll on the system. I should look down that route more. > 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. > Regards, > > Arthur Thanks for providing an opportunity to see how the assumptions I made were a bit ... too presumptuous... --- 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.
