ctor_copy_dtor.cc still consuming outrageous amounts of memory

[Nix]

On Mon, 29 Jan 2001, Phil Edwards uttered the following:
>> What to do, what to do...  I'll add a call to 'ulimit -v' and see what
>> the memory limit needs to be set to, for starters.
> 
> With this patch, I get no nasty memory hoggers, and results of:

Pretty much what I did, but neater. You were looking for a neat
solution; I was looking for `stop this damned thing killing my
machine!'...

btw, the stupidly overdesigned solution would be an autoconf test that
looks at the return values of calls to malloc() with different sizes, to
determine when and if malloc()'s implementation ever thunks to mmap().

(But I don't encourage implementation of that little monster. Comparing
pointer values is always a portability nightmare.)

>     pass/fail results:  98/3 shared + 98/3 static = 196/6 total
> 
> The three failing tests are the usual map/set operators, and a runtime
> failure of 27_io/ios_base_members_static.

This seems to be unrelated to memory consumption; I get that with memory
limits of 256Mb. The test's just not returning the right answer (and
failing `conventionally'), I think.

>                                           Sweet.  Do we want to increase
> the memory limit that much, however?  We started at 2MB for a reason.

I dunno. I'll try running with 8Mb as the limit and see if anything
extra fails. A search downwards towards 2Mb looking for the lowest limit
which works seems right.

(Even better would be a way to override that limit for individual `mild
hog' tests. No point even thinking about that until the migration to
dejagnu is done, though.)

-- 
`Anyhow, that pipe dream doesn't say anything about the question you
 asked.  (I am planning for a career in politics.)' --- Mark Mitchell
                                                      on the GCC list