A milestone - the first TESTFRAME capture
Eric S. Raymond
esr at thyrsus.com
Wed Dec 9 06:01:42 UTC 2015
Hal Murray <hmurray at megapathdsl.net>:
>
> esr at thyrsus.com said:
> >>> I think I've worked out a way not to have to capture random-number calls.
> > Simple. If I record events for every place that *uses* the RNG with whatever
> > value it extracted, I don't have to track every single RNG call.
>
> I think that only works in a few special cases. For example, ntp_gettime
> uses random to fuzz the bottom bits so you don't need to intercept that
> randomness if you are intercepting ntp_gettime.
>
> Here is an example where you can't intercept where it is used:
>
> Yesterday, I fixed a couple of coverity complaints about using rand(), so I
> learned a bit about that code. It is randomizing the order of returning
> named slots in a clump of data. (The idea was to force clients to process
> the answer in any order so ntpd wouldn't get stuck with preserving the order
> if that code area ever changed.)
>
> I don't see how you can preserve the content of the packets that routine is
> constructing without feeding it the same randomness to work with.
Yes, there are a few other cases like this. What I'd have to do is treat
every piece of randomly-generated state - like the scramble vector for the
slots - as the payload of an event to be saved and replayed.
My current thinking is that this is not worth the additional complexity
it would require in the replay log format, and that it is less bad to have
it cluttered with "random" events.
Once I get replay working, I'll try omitting the trip through the intercept
layer for random() calls I'm not interested in and see if that preserves
reproducibility. I think it might.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel
mailing list