This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ 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: Stephen M. Webb <stephen at bregmasoft dot com>
- Date: Fri, 3 Aug 2001 20:57:04 -0400
- 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>
- Organization: CRYPTOCard Corporation
- References: <Pine.BSF.4.30.0108022218370.48766-100000@dair.pair.com>
- Reply-To: stephen at bregmasoft dot com
On Thu, 02 Aug 2001, Hans-Peter Nilsson wrote:
> On Thu, 2 Aug 2001, Phil Edwards wrote:
> > 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.
>
> 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. ;-)
Perhaps the solution is as simple (?) as modifying new and allocator::allocate
so that they are aware of getrlimit and getrusage values, and throw if a memory
allocation request would exceed those values. Changing malloc is probably not
such a good idea, but new and allocator::allocate have better-defined
behaviour and are under C++ standard library control.
A build-time check would be necessary for such support, but on those platforms
without getrusage and getrlimit, you'd be no further behind.
_______
Stephen m. Webb