On Thu, 19 Sep 2013, Dave Jones wrote: > It might be worth looking at Vince's perf fuzzer to see what he's done there > for bisecting/generating test cases. my perf_fuzzer doesn't do anything that complicated. In its current setup it only has one thread, which occasionally forks off a child but it always kills the child before forking off another. I find the run-to-run reproducibility of traces to be surprisingly consistent when given the same random seed. Even hundreds of thousands of syscalls in I can usually hit the same bugs at roughly the same syscall count. I find this suprising because when perf events are involved nothing is deterministic; if you are measuring things like cycles with overflow, the cycle count is going to depend on what else is going on in the system, and if your overflow handler consumes randomness (hard because rand() isn't signal-handler safe, but possible with a few hacks) you'd expect things ro diverge. As for bisecting, my major problem is dependent syscalls, something that might not be as big an issue on trinity. The way perf_fuzzer is set up you open an fd with perf_event_open(), then lots of other syscalls act on the fd. So if your bisect happens to cut off the open of the fd, then all subsequent dependent syscalls fail. I don't have a good automatic solution to that, I've so far been placing the bisect points by hand and just having the replayer be robust in cases where invalid dependent syscalls appear in the trace. perf_fuzzer also has a somewhat human-readable log format, which wastes disk space but makes it easier to do somewhat manual bisects using a text editor. Vince -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
