Re: memory exhausted

On Nov 13, 2008, at 4:00 PM, Todd Denniston wrote:

> Paul Sander wrote, On 11/13/2008 05:28 PM:
>> I found the mmap in CVS 1.11.23, and would not be at all surprised  
>> to find it also in the unstable release that Alex is using.  I'm  
>> certain it's been in CVS since CVS absorbed RCS.
>
> I don't think it has been quite that long, at least on solaris.
> http://lists.gnu.org/archive/html/bug-cvs/2003-11/msg00152.html
>
> mmap happened between 1.11.1p1 and 1.11.2.
> the solaris mmap patches I applied for solaris 2.6 did not help.
>
> At least in the 1.11.x series you could drop mmap by:
> after you configure (but before compile) of cvs Version >1.11.1p1   
> make the
> following change in config.h:
>
> diff config.h.normal config.h
> 199c199
> < #define HAVE_MMAP 1
> ---
> > /*#define HAVE_MMAP 1*/
>
> then `make; make install`
>
> and if you felt like it, you could follow some of my other  
> suggestions about having mmap problems :)
> http://lists.gnu.org/archive/html/info-cvs/2003-12/msg00300.html

Keep in mind that with mmap turned off, CVS reads the RCS file into a  
malloc buffer that gets realloc'ed as it overflows.  Under conditions  
where the entire RCS file is read, which is just about anything that  
reads beyond the initial admin section (including every commit and tag  
operation, and most log operations), this can be inefficient and cause  
a swap space overflow even if much of the heap is unused.

If I recall correctly, RCS had a large-memory non-mmap option that  
would stat the RCS file and allocate a single buffer large enough to  
accommodate it, and read it all in at once.  This was in addition to  
the slower small-memory method that never read the entire RCS file  
into memory.  It would be nice if CVS incorporated these capabilities,  
too.  A bonus would be to fall back to the small memory method if it  
anticipates a shortage of memory based on current consumption and  
system limits.