This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ test suite still drives machine into swap
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: libstdc++ test suite still drives machine into swap
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Thu, 2 Aug 2001 22:28:40 -0400 (EDT)
- cc: Zachary Weinberg <zackw at panix dot com>, Benjamin Kosnik <bkoz at redhat dot com>, <gcc at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>
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. ;-)