libstdc++ test suite still drives machine into swap

[Hans-Peter Nilsson]

On Thu, 2 Aug 2001, Phil Edwards wrote:
> 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."
>
> If allocation fails, we need to make sure that bad_alloc is thrown (as
> opposed to throwing something else, or not throwing anything and just
> returning).  There's nothing "after" that code, really, at least nothing
> that we're specifically testing there and nowhere else.  If it succeeds,
> fine, if it fails and throws bad_alloc, fine, anything else (that we can
> control) is not fine.
>
> 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.

Nosy bystander chimes in: Wouldn't the same argument apply for
using setrlimit during testing?

On the surface this problem looks very much like it would be
solved by just linking those tests with a special-purpose Very
Simple malloc library that fails for Large Chunks, avoiding
side-effects of the host library overcommitting.  (Though
perhaps those systems are then not usable as host systems. ;-)

brgds, H-P