This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ test suite still drives machine into swap
- To: Zachary Weinberg <zackw at panix dot com>
- Subject: Re: libstdc++ test suite still drives machine into swap
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Thu, 2 Aug 2001 19:21:30 -0400
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- References: <20010802184141.A4870@panix.com>
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."
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.
(Am I making sense? Feels like we're talking past each other.)
> 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?
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
- anonymous Egyptian scribe, c.1700 BC