RE: Process record and replay checked in to main trunk

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Hui Zhu
> Sent: Sunday, May 03, 2009 10:16 AM
> To: Eli Zaretskii
> Cc: gdb-patches@sourceware.org
> Subject: Re: Process record and replay checked in to main trunk
> 
> On Sat, May 2, 2009 at 01:55, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sat, 2 May 2009 01:02:33 +0800
> >> From: Hui Zhu <teawater@gmail.com>
> >> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com,
> >> ? ? ? marc.khouzam@ericsson.com, msnyder@vmware.com, 
> bauerman@br.ibm.com,
> >> ? ? ? mark.kettenis@xs4all.nl
> >>
> >> > What I think is still missing from the manual is a few 
> sentences that
> >> > would explain when this target is useful. ?Can you 
> provide such ``war
> >> > stories''? ?I will then add them to the manual.
> >>
> >> Which sentences? ``war stories''?
> >> Do you mean is internal doc?
> >
> > No, I mean description of when this target is useful in 
> real life, and
> > how you will use it. ?In other words, put yourself in a place of
> > someone who reads the manual about the record/replay target and asks
> > him/herself "why should I care about this new feature?" ?Then try to
> > answer that question. ?And try to answer it so that the reader will
> > wonder how could she ever get by without this feature before.
> >
> 
> I got it.  I will try to deal with it.
> 
> I am not a native speaker and poor english ability.
> Could some people help me with it?

These points will not be a surprise to anyone, but I figure 
they may help get the ball rolling.
Some of the values that I find in Process Record and Replay are:

a) Debugging a problem that requires a lot of user input.  

Say my software is a graphical application and I get a 
report that a specific long sequence of user-interface operations 
causes a bug.  Fixing the bug requires me to reproduce it by 
repeating the many UI operations until I arrive at the point of 
execution where the bug occurs.  If I have to go over the problematic
part of the execution multiple times, traditional debugging requires
me to manually repeat the long sequence of UI steps over and over, 
until I have collected all the necessary information.

With Process Record and Replay, the pressure of obtaining as much 
information as possible in a single run is removed.  If I need to 
collect more information that I originally thought, it is now possible 
to simply reverse the execution up to the point I'm interested in, and 
repeat the execution forward again, collecting the info that was missed.
The long sequence of UI steps need only be done once.

b) Debugging a race condition

In cases where the bug I am chasing is caused by a race condition,
reproducing the problem may take dozens (or more) of attempts.  Again, in
such cases, the pressure is on to collect as much information as possible
on the first run, as it may be very diffucult to re-trigger the race
condition.

With Process Record and Replay once the race condition has been reproduced,
the execution can be reversed and repeated as many time as required to
collect all necessary information.  The race condition is guaranteed to be
present in the replay of the execution since it is simply repeating the
exact execution that was previously recorded.

c) Unknown sequence of events leading to a bug

Sometimes, while testing an application, an unexpected behavior will
be seen.  Unfortunately, the designer often does not recall the exact
events that lead to this behavior and cannot reproduce it.  The situation
is then labelled 'a fluke'.

In some cases, the testing of an application can be done with Process 
Record and Replay enabled.  In such cases, when an application misbehaves,
the events leading to that point have been recorded and can be replayed
immediately and investigated thoroughly.  Bugs can no longer escape
through the 'fluke' door.