This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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. ;-)

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]