This is the mail archive of the mailing list for the libstdc++ project.

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

libstdc++ test suite still drives machine into swap

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.

The last time I brought this up I tried to explain why these tests
shouldn't be done at all and no one got it.  Code like

  try {
    csz01 = str01.max_size();
    std::string str03(csz01 - 1, 'A');
    VERIFY( str03.size() == csz01 - 1 );
    VERIFY( str03.size() <= str03.capacity() );
  } catch (std::bad_alloc) {
    VERIFY (true);

*does not test* that size() is equal to csz01 - 1 or <= capacity().
It doesn't even test that std::bad_alloc is thrown.

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.  Then the operating system kills the process - if you're
lucky - while it's trying to write 'A' over a gigabyte of virtual
memory that the computer does not actually have.[1]

The *only* way you can test std::bad_alloc reliably is to override
libc malloc with something that fails on huge requests.  Resource
limits are not sufficient.  Assuming that malloc will return NULL 
most certainly does not cut it.

The *only* way you can test the constraints on max_size, size,
capacity, etc. is if you can somehow create a basic_string<>
instantiation for which max_size is small enough that you *can*
allocate that much memory without bringing the computer to its knees.[2]

[Sample code above was taken from 21_strings/  That
particular test has been #if 0'ed out with a comment referencing one
of the previous threads on this subject.  However, not all the tests
with this problem have been disabled.  Right now I'm not sure which
test is the current problem.]

[I might add that surely it is only necessary to test this sort of
thing *once*, not the five or six times it appears to be done in the
current test suite.]

zw   The beginning of almost every story is actually a bone, something with
     which to court the dog, which may bring you closer to the lady.
     	-- Amos Oz, _The Story Begins_

[1] If you're unlucky, the computer crashes, or the operating system
kills half a dozen random innocent processes before it hits the one
that's eating all the memory.

[2] I tried to figure out how to do that and got lost in a maze of
twisty little template classes.  But I don't really speak C++.  I
would suggest that #define __STD_STRING_MAX_SIZE or some such should
override the default for std::string's max_size() method.

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