From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14627 invoked by alias); 5 May 2009 14:11:18 -0000 Received: (qmail 14618 invoked by uid 22791); 5 May 2009 14:11:17 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.188) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 May 2009 14:11:05 +0000 Received: by ti-out-0910.google.com with SMTP id a1so453302tib.12 for ; Tue, 05 May 2009 07:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.16.15 with SMTP id 15mr5035tip.53.1241532662962; Tue, 05 May 2009 07:11:02 -0700 (PDT) In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA076040E1@ecamlmw720.eamcs.ericsson.se> References: <833abpdvzy.fsf@gnu.org> <83ljpgd7xv.fsf@gnu.org> <6D19CA8D71C89C43A057926FE0D4ADAA076040E1@ecamlmw720.eamcs.ericsson.se> Date: Tue, 05 May 2009 14:11:00 -0000 Message-ID: Subject: Re: Process record and replay checked in to main trunk From: Hui Zhu To: Marc Khouzam Cc: Eli Zaretskii , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00086.txt.bz2 On Mon, May 4, 2009 at 22:32, Marc Khouzam wrot= e: >> -----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 wrote: >> >> Date: Sat, 2 May 2009 01:02:33 +0800 >> >> From: Hui Zhu >> >> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com, >> >> =A0 =A0 =A0 marc.khouzam@ericsson.com, msnyder@vmware.com, >> bauerman@br.ibm.com, >> >> =A0 =A0 =A0 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. =A0Can you >> provide such ``war >> >> > stories''? =A0I 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. =A0In 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?" =A0Then try to >> > answer that question. =A0And try to answer it so that the reader will >> > wonder how could she ever get by without this feature before. >> > >> >> I got it. =A0I 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. =A0Fixing 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. =A0If 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. =A0If 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. =A0Again, = 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 reproduce= d, > the execution can be reversed and repeated as many time as required to > collect all necessary information. =A0The 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. =A0Unfortunately, the designer often does not recall the exact > events that lead to this behavior and cannot reproduce it. =A0The situati= on > is then labelled 'a fluke'. > > In some cases, the testing of an application can be done with Process > Record and Replay enabled. =A0In such cases, when an application misbehav= es, > the events leading to that point have been recorded and can be replayed > immediately and investigated thoroughly. =A0Bugs 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