Re: [Valgrind-developers] Record/replay support in valgrind

[James C. <cl...@cc...>]

Mojiong

I think this work sounds great.  I've done a good deal of work on  
capture / replay systems; you can check out my  webpage (www.cc.gatech.edu 
~clause) for some additional information some of the techniques I've  
come up with.

I think the main reason that no one has done this before is simply  
because no one has gotten around to it.  There's also a few similar  
tools like Jockey (http://home.gna.org/jockey/) that make it less  
interesting from an academic standpoint.

The thing that excites me the most is that you've got an analysis  
working on the replay.  This is something that's been talked about a  
lot but hasn't really had a good implementation.

Are you willing to share your code?  If you put it out there some  
other people may help you fill in the details.

~Jim

On Jul 23, 2008, at 6:39 PM, MoJiong Qiu wrote:

> Hi,
>     I am a new valgrind hacker. I apologize if this question has  
> been raised and discussed before.  I'm interested in recording a  
> program execution with valgrind and replaying it in valgrind with  
> added analysis.
>
>     I have spent some time implementing a prototype of record and  
> replay in the valgrind core based on intercepting and recording  
> syscall results and playing back their results.  So far, I have only  
> wrapped a dozen or so syscalls and valgrind only records and replays  
> small single threaded programs.  I am able to record execution for  
> these small programs with this modified valgrind core with no  
> analysis, and have the core replay the execution while turning on  
> instrumentation and analysis (I turned on cachegrind while  
> replaying).  More complex client programs can be supported as more  
> syscalls are recorded and replayed.  It doesn't currently support  
> multithreading or signal delivery, though I expect recording and  
> replaying these should be doable as well.
>
>     In my prototype, no valgrind tools are needed during recording,  
> hence recording is 2-4x slowdown (roughly the overhead of nullgrind  
> itself).
> Valgrind tools like cachegrind can be enabled during replay (in  
> theory memcheck can be supported too, but requires a little more  
> work on the recording end to deal with its changes to the memory  
> allocator).
>
>     Why record and replay?  The recording overhead is roughly  
> comparable to nullgrind, which will generally be smaller  
> (potentially much
> smaller) than directly doing the analysis.  This means it can be  
> more efficient to record a phenomenon and analyze its execution  
> after it has been captured.  This is particularly good for capturing  
> executions that aren't easily reproducible, like those triggered by  
> external inputs (e.g., querying results from a database).  Record  
> and replay can capture the buggy executions and enable more  
> effective debugging.
>
>     Second, for interactive programs, say firefox, the slowdown  
> caused by online memcheck may be too high for user interaction.   
> Record and replay moves this slowdown to replay time, when the  
> playback is automated.
>
>     So my questions is that it seems record and replay is not too  
> difficult to do in valgrind and it is useful.  But why hasn't anyone  
> done it?  Am I missing something that is too difficult to do?  Is  
> there not enough benefits?
>
> Thanks,
> Mojiong
>
> Discover the new Windows Vista Learn more!  
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers