From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18828 invoked by alias); 14 Sep 2009 17:10:53 -0000 Received: (qmail 18706 invoked by uid 22791); 14 Sep 2009 17:10:51 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk) (212.23.3.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 17:10:46 +0000 Received: from [82.69.137.158] (helo=[10.17.20.102]) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1MnF4c-0008Vz-1X; Mon, 14 Sep 2009 17:10:42 +0000 Message-ID: <4AAE7910.5040907@undo-software.com> Date: Mon, 14 Sep 2009 17:10:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Hui Zhu CC: Marc Khouzam , "gdb@sourceware.org" , Michael Snyder , gdb-patches ml Subject: Re: PRecord sets memory even when it says it did not References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.69.137.158] 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-09/txt/msg00413.txt.bz2 Hui Zhu wrote: > On Mon, Sep 14, 2009 at 09:54, Marc Khouzam wrote: >> Hi Hui, >> >> I'm seeing PRecord changing memory even though I answer >> the query as to not change it. Please see below. >> >> Thanks >> >> Marc >> >> GNU gdb (GDB) 6.8.50.20090913-cvs >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /home/marc/testing/a.out...done. >> (gdb) l >> 1 int main() { >> 2 int a = 1; >> 3 int b = 10; >> 4 >> 5 a++; >> 6 b++; >> 7 >> 8 return a; >> 9 } >> 10 >> (gdb) start >> Temporary breakpoint 1 at 0x80483f5: file b.cc, line 2. >> Starting program: /home/marc/testing/a.out >> re >> Temporary breakpoint 1, main () at b.cc:2 >> 2 int a = 1; >> (gdb) record >> (gdb) n >> 3 int b = 10; >> (gdb) n >> 5 a++; >> (gdb) n >> 6 b++; >> (gdb) rn >> 5 a++; >> (gdb) p a >> $1 = 1 >> (gdb) set var a = 8 >> Because GDB is in replay mode, writing to memory will make the execution log unusable from this point onward. Write memory at address 0xbffff6a0?(y or [n]) n >> Process record canceled the operation. >> (gdb) p a >> $2 = 8 >> > > > > Hi Marc, > > Thanks for your help. > > I just tried change it with "p a=99". I think it must have something > different with "set var a = 8". I've noticed something similar with UndoDB. Until very recently, if we failed a 'poke' operation (which we do when in replay mode) the data would not be changed. But with a recent gdb built from cvs (as of about two weeks ago), despite UndoDB failing the poke, the value still appears to the user to have been written. Could this be related to the caching changes that have happened recently? i.e. does the cache get updated even though the underlying poke operation failed? If so, this issue would seem to be wider than just prec (and wider than reverse, too). Cheers, Greg -- Greg Law, Undo Software http://undo-software.com/