Re: libstdc++ test suite still drives machine into swap

["Zack Weinberg" <zackw@Stanford.EDU>]

On Wed, Jun 27, 2001 at 12:10:26PM +0200, Wolfram Gloger wrote:
> Hello,
> 
> > The libstdc++ test suite still drives my machine, which has plenty of
> > RAM thank you, into swap.  I suspect this is because ulimit -d does
> > not actually work on Linux, because libc allocates huge blocks with
> > anonymous mmap, and anonymous mmap ignores that particular limit.
> 
> Yes, so if you want to limit RAM usage, why not just use 'ulimit -v'?

Well, for one thing, with my /bin/sh:

$ ulimit -v 2048
ulimit: Illegal option -v

I suppose we could wire a setrlimit(RLIMIT_AS, ...) call into the test
case itself - frankly, that is also the only way I'd be confident that
the limit actually affected the relevant process.

But that's not the right call to make on other systems.  If we went
this way, it would make sense to export a helper function from
libstdc++ that did the Right Thing for you.

> > What actually happens is that execution never gets past the
> > std::string constructor.  Malloc lies.  It gives you a pointer to
> > memory that does not exist, on the theory that you won't *really* use
> > all of it.
> 
> Actuallly, I think it's more accurate to state that the kernel lies.
> But we all like over-commitment, don't we..

True enough.  I've seen people argue that overcommitment is a
violation of the C standard (not that I necessarily agree).  The
program certainly can't tell whether it's the kernel or the C library
doing the lying...

-- 
zw     I *will* wrestle it into shape eventually. I *will* clean it out,
       *without* resorting to the redirection of a major navigable river.
       	-- Ray Radlein on lumber rooms