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

[Bulgrien, Kevin]

> -----Original Message-----
> From: Arthur Barrett [mailto:address@hidden 
> Sent: Wednesday, November 12, 2008 2:55 PM
> To: Bulgrien, Kevin; address@hidden
> 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.