Hi,
Bart Van Assche wrote:
> I think that it is possible to implement a record/replay tool for
> multiple processes without modifying the Valgrind scheduler. During
> the recording phase you can gather information about any event that
> influences interprocess ordering by intercepting system calls like
> recv(), send(), sendto(), kill(), ... During the replay phase you can
> intercept the same system calls and delay their execution in such a
> way that scheduling during replay matches scheduling during the
> recording phase.
Hm.. that's a point. But using mainly shared memory for inter process
communication, this won't help, because there's no (or only few) system
calling involved. So the scheduling might very well differ.
I'm also unclear on how easy it would be to "construct" the wanted
situations. Especially if the underlying code changes, so that the
issued system calls suddenly don't match the recorded ones anymore.
But yeah, extending that scheme to not only system calls, but also
events like entering a function or hitting a trace point could help.
Coupled with a loose recording definition, more event based, like:
- after entering function foo execute until syscall signal() is
issued, then interrupt the process (thread) until condition bar
is reached.
These are the kinds of rules which would allow me to specifically test
certain situations which a natural scheduler reaches only very rarely,
but could lead to an error.
Thanks for making me think more about record/replay, looks like I should
investigate somewhat more on what exists in that area.
Regards
Markus
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
