Re: libstdc++ test suite still drives machine into swap

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Thu, Aug 02, 2001 at 07:40:10PM -0400, Zack Weinberg wrote:
> On Thu, Aug 02, 2001 at 07:21:30PM -0400, 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."
> 
> I've misunderstood then.  This snippet (from ctor_copy_dtor.cc) very much
> reads as if it's the size() and capacity() invariants (inside the try block)
> that are meant to be tested.

Yeah... we're really testing one of two possible outcomes.  /If/ it works,
then we /also/ need to check the size() and capacity() invariants.  /If/
it fails, then we /also/ need to check the failure mode.

The fact that the test has caused this much confusion points up its lack
of a good comment, I guess.  Once we hammer out a good strategy, I'll
write something better above the tests.


> > 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.
> 
> I'm not aware of any implementation under which malloc will succeed if you
> try to allocate a chunk of memory larger than the total memory rlimit all
> at once.  (Is that sentence clear?)

I think it's clear... the test is almost guaranteed to fail, unless the
user has chunkloads of virtual memory, in which case we still have to do
the right thing- arrg.  If we all agreed to go back to 16-bit size_t's
this problem would go away.  :-|


Phil

-- 
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