Re: cvs commit: apr/test testshm.c

[Joe Orton <jo...@manyfish.co.uk>]

On Sat, May 15, 2004 at 07:51:50PM -0000, Ryan Bloom wrote:
> rbb         2004/05/15 12:51:50
> 
>   Modified:    test     testshm.c
>   Log:
>   If we can't create the shared memory segment, don't try to keep going
>   through the test.  Doing so causes a segfault to occur.  Re-enable this
>   test.

Oh, I hadn't realised that assumption had changed.  Where are you going
with this?  Without the assumption that a failed test causes a longjmp
out of the test function, the entire suite is unreliable, it will
segfault in so many failure cases...

joe

Re: cvs commit: apr/test testshm.c

[rb...@rkbloom.net]

On Sun, 23 May 2004, Joe Orton wrote:

> On Sat, May 15, 2004 at 07:51:50PM -0000, Ryan Bloom wrote:
> > rbb         2004/05/15 12:51:50
> >
> >   Modified:    test     testshm.c
> >   Log:
> >   If we can't create the shared memory segment, don't try to keep going
> >   through the test.  Doing so causes a segfault to occur.  Re-enable this
> >   test.
>
> Oh, I hadn't realised that assumption had changed.  Where are you going
> with this?  Without the assumption that a failed test causes a longjmp
> out of the test function, the entire suite is unreliable, it will
> segfault in so many failure cases...

Yes, but the longjmp is gone now.  One day I will have the time to go
through the suite and fix the tests.  For now, I'm not overly concerned
about the seg faults.  Think about it this way, if you ran a test suite
and it seg faulted on your box, would you trust the port?  The goal of the
test suite is to prove that the port to this platform is correct.  If it
is segfaulting, then the port isn't correct.

Ryan