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

[Zack Weinberg <zackw at panix dot com>]

On Thu, Aug 02, 2001 at 07:21:30PM -0400, Phil Edwards wrote:
> On Thu, Aug 02, 2001 at 06:41:41PM -0400, Zachary Weinberg wrote:
> > Allocating and initializing a string of
> > max_size() can only succeed on a machine with more than a gigabyte
> > of virtual memory.  On a normal machine with less memory, either
> > the process dies, or bad_alloc is thrown.  Either way, the actual
> > test - the code intended to be executed after the allocation
> > completes - never gets executed.
> 
> That /is/ the test.  It's not only "test big strings," it's also "test
> the failure mode of string::allocator running out of memory."

I've misunderstood then.  This snippet (from ctor_copy_dtor.cc) very much
reads as if it's the size() and capacity() invariants (inside the try block)
that are meant to be tested.

  // Build a maxsize - 1 lengthed string consisting of all A's
  try {
    std::string str03(csz01 - 1, 'A');
    VERIFY( str03.size() == csz01 - 1 );
    VERIFY( str03.size() <= str03.capacity() );
  }              
  // NB: bad_alloc is regrettable but entirely kosher for
  // out-of-memory situations.
  catch(std::bad_alloc& fail) {
    VERIFY( true );
  }
  catch(...) {
    VERIFY( false );
  }

same deal with the problematic tests in insert.cc.

> I don't think we have any control over whether the kernel guns the process
> rather than malloc setting ENOMEM.  We could perhaps replace malloc() with
> our own version, but then we're not testing the same execution environment
> that the users would have.

I'm not aware of any implementation under which malloc will succeed if you
try to allocate a chunk of memory larger than the total memory rlimit all
at once.  (Is that sentence clear?)

> > The problem of the machine getting driven into swap by the test is
> > an independent problem with the same cause.  I would suggest that
> > that one be solved by adding a utility routine to libstdc++ which
> > makes the appropriate setrlimit() calls to constrain process memory,
> > and then calling it from test cases that are known to thrash the computer.
> 
> That's a very good idea.
> 
> I'm familiar with ulimit at the shell level but not the underlying calls.
> Do we need anything other than a simpleminded setrlimit() autoconf test,
> i.e., is the function signature fairly well-standardized across platforms
> which have it?

To the best of my knowledge it's always int setrlimit(int, struct rlimit *);
The tricky bit is that the appropriate RLIMIT_* constant varies with the
operating system - RLIMIT_DATA, RLIMIT_RSS, RLIMIT_AS, etc.  It may work
to set all of the limits that are #defined.

zw