Re: Process record and replay checked in to main trunk

[Hui Zhu <teawater@gmail.com>]

On Mon, May 4, 2009 at 22:32, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
>> -----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.

Wow.  These cover most of words I want to say.  Thank you very much.  :)
I posted this url to wiki.


Hui