From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2026 invoked by alias); 11 Jun 2009 01:42:51 -0000 Received: (qmail 2018 invoked by uid 22791); 11 Jun 2009 01:42:50 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f196.google.com (HELO mail-px0-f196.google.com) (209.85.216.196) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Jun 2009 01:42:44 +0000 Received: by pxi34 with SMTP id 34so342729pxi.12 for ; Wed, 10 Jun 2009 18:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.84.5 with SMTP id h5mr785215wfb.200.1244684562072; Wed, 10 Jun 2009 18:42:42 -0700 (PDT) In-Reply-To: References: <5cfa99000906021448y5a7b4418l8578052bbd79757e@mail.gmail.com> <6D19CA8D71C89C43A057926FE0D4ADAA0786E824@ecamlmw720.eamcs.ericsson.se> <5cfa99000906021850s5bdb4a94t8bdea5b254936ddf@mail.gmail.com> Date: Thu, 11 Jun 2009 01:42:00 -0000 Message-ID: Subject: Re: industrial use of 'record' and replay. From: Hui Zhu To: Toby Haynes , Edward Peschko , Marc Khouzam Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00104.txt.bz2 On Wed, Jun 10, 2009 at 03:39, Toby Haynes wrote: >> Edward Peschko >> 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. > > Picking up on this, is it possible to configure the record to use a > circular buffer, effectively recording only the most recent events? Even > better if we can specify the size or number of events on that buffer. > > If, for example, I wanted to use this to debug a crash problem in a large > project (where large implies more than 1Gb of source code, with multiple > processes and threads), being able to set reasonable bounds for recording > will be critical to make use of this facility. Doubly so in scenarios > which fail stress tests after more than 24 hours of operation. Being able > to rewind from the crash point to see precisely what lead to the crash > would be a killer feature, with huge time savings. > I think implement a circular buffer is very hard to precord. Because precord need the all the memory of inferior. But I have another idea to implement the example: Set 1 breakpoint at the begin of code that you want record and use "commands" let precord begin work at there. Set another breakpoint at the end of code that you want record and use "commands" gcore, dump record message, stop record. Then, when you want analyze the bug of this code, you can use the core file(It will help prec get inferior memory) and record dump message to do it. Now, prec still not support dump record message and multi-thread. I am dealing with them. Thanks, Hui