This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]