Re: PRecord sets memory even when it says it did not

[Greg Law <glaw@undo-software.com>]

Hui Zhu wrote:
> On Mon, Sep 14, 2009 at 09:54, Marc Khouzam <marc.khouzam@ericsson.com> 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 <http://gnu.org/licenses/gpl.html>
>> 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:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> 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/