Karl Fogel wrote:
> "Kirby C. Bohling" <kbohling@birddog.com> writes:
>
>>>Maybe we can think of some way to test for killability in the client?
>>>
>>No that isn't exactly a portable solution (won't work on Windows). I
>>don't know of anything else that gives you "killable" tests that are
>>repeatable. Just an idea if you really want to try that. The worst
>>thing about it is the warts in the code with randomFailure. We ended
>>up moving it to an extremely low level library that everybody
>>referenced and left it there. Then commented the heck out of it. I
>>would guess that pool creation would be my chosen place in the SVN
>>code.
>>
>
> We don't have to do random failures -- we can have chosen failure
> points, set off by a special command-line flag (for example).
>
> $ svn --fail-point=LABEL ...
>
> Then the tests would be repeatable. (Of course, we can use random
> processes to help choose the points.)
>
> We'd still have to have those conditional exits scattered throughout
> the code, but it would be worth it IMHO.
>
> -K
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
We did random to avoid finding them by hand (lazy programmers, I know
it's shocking), and essentially did stress testing to show it worked
(not much for proof). The only bothersome piece about labelling the
failure points, is sometimes I want it to fail, after the hundredth
interation of passing that point. We found that lots of failure
conditions were handled reasonable well during early stages, but nested
failures deep in the belly of recursive calls weren't handled correctly.
You can either do that by using gdb and a script or extending the syntax
of fail-point a bit. If it where me, I would make the label a function
call so you can set a breakpoint on it and not call use --fail-point on
the command line for debugging and let the process continue running. It
also makes the failure points a bit cleaner in the code.
We did a similar dance of just generating random error codes on malloc,
and put wrappers around important calls that would cause plausible
failures randomly to see that all of the error conditions were handled
correctly as opposed to just the program randomly dying.
Food for thought along those lines. You guys are sharper then me, so
I'll be interested to see how you solve the problem.
Kirby
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 15 21:15:20 2002