From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27268 invoked by alias); 3 Jun 2009 01:50:57 -0000 Received: (qmail 27005 invoked by uid 22791); 3 Jun 2009 01:50:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-gx0-f157.google.com (HELO mail-gx0-f157.google.com) (209.85.217.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 01:50:45 +0000 Received: by gxk1 with SMTP id 1so14495227gxk.0 for ; Tue, 02 Jun 2009 18:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.145.20 with SMTP id x20mr861562ybn.274.1243993842083; Tue, 02 Jun 2009 18:50:42 -0700 (PDT) In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA0786E824@ecamlmw720.eamcs.ericsson.se> References: <5cfa99000906021448y5a7b4418l8578052bbd79757e@mail.gmail.com> <6D19CA8D71C89C43A057926FE0D4ADAA0786E824@ecamlmw720.eamcs.ericsson.se> From: Edward Peschko Date: Wed, 03 Jun 2009 01:50:00 -0000 Message-ID: <5cfa99000906021850s5bdb4a94t8bdea5b254936ddf@mail.gmail.com> Subject: Re: industrial use of 'record' and replay. To: Marc Khouzam Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00022.txt.bz2 >> However, I had a few questions, about 'scaling up' the use of this: >> >> =A0 =A0 1. Suppose that one has an extremely long process, one >> which takes hours to >> =A0 =A0 =A0 =A0 'get' to the bug.. How can one 'short circuit' this proc= ess so >> that you don't need >> =A0 =A0 =A0 =A0 to replay for hours to get to it? > > I'm not sure I understand. > Do you want to avoid the 'long execution' all together or do you want > to avoid executing it with Recording enabled? =A0Can you predict about > where in the program the bug occurs? What I want to do is record a program, but not necessarily have to replay it from the start of its recording - ie: have the system automatically take 'snapshots' of the state at given intervals, and then have the ability to replay from any given snapshot. Since this would be used in a test suite, I'd like it to be automatable, ie: set up in a config file, and then run without any interaction with the user. One could then run the test suite, and in the case of 'interesting events' take the latest version of the snapshot and run it from that point (rather than from the beginning of the run, which may be hours before). If the 'true' bug lies before the latest snapshot, go back to the previous snapshot (and the one previous) until the bug itself is found. Anyways, looking at your reply and reading about checkpoints, I'm not sure if they apply here. Maybe someone more familiar with the internals of record/replay= can comment.. Thanks much, Ed