From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6139 invoked by alias); 4 May 2009 14:32:31 -0000 Received: (qmail 6128 invoked by uid 22791); 4 May 2009 14:32:30 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 May 2009 14:32:22 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n44Eg9B0001070; Mon, 4 May 2009 09:42:12 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 09:32:13 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Process record and replay checked in to main trunk Date: Mon, 04 May 2009 14:32:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA076040E1@ecamlmw720.eamcs.ericsson.se> In-Reply-To: References: <833abpdvzy.fsf@gnu.org> <83ljpgd7xv.fsf@gnu.org> From: "Marc Khouzam" To: "Hui Zhu" , "Eli Zaretskii" Cc: 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/msg00058.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [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 >=20 > 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,=20 > bauerman@br.ibm.com, > >> =A0 =A0 =A0 mark.kettenis@xs4all.nl > >> > >> > What I think is still missing from the manual is a few=20 > sentences that > >> > would explain when this target is useful. =A0Can you=20 > 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=20 > 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. > > >=20 > I got it. I will try to deal with it. >=20 > 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=20 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.=20=20 Say my software is a graphical application and I get a=20 report that a specific long sequence of user-interface operations=20 causes a bug. Fixing the bug requires me to reproduce it by=20 repeating the many UI operations until I arrive at the point of=20 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,=20 until I have collected all the necessary information. With Process Record and Replay, the pressure of obtaining as much=20 information as possible in a single run is removed. If I need to=20 collect more information that I originally thought, it is now possible=20 to simply reverse the execution up to the point I'm interested in, and=20 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=20 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.