This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

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 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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]