This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: PRecord sets memory even when it says it did not
- From: Marc Khouzam <marc dot khouzam at ericsson dot com>
- To: "'Greg Law'" <glaw at undo-software dot com>, "'Hui Zhu'" <teawater at gmail dot com>
- Cc: "'gdb at sourceware dot org'" <gdb at sourceware dot org>, "'Michael Snyder'" <msnyder at vmware dot com>, "'gdb-patches ml'" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2009 13:18:47 -0400
- Subject: RE: PRecord sets memory even when it says it did not
- References: <F7CE05678329534C957159168FA70DEC5153600749@EUSAACMS0703.eamcs.ericsson.se> <daef60380909132139k46f577aet63f4089a97138368@mail.gmail.com> <4AAE7910.5040907@undo-software.com>
> -----Original Message-----
> From: Greg Law [mailto:glaw@undo-software.com]
> Sent: Monday, September 14, 2009 1:11 PM
> 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
>
...
>
> 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).
This does seem to be a recent problem because Hui had fixed it
on July 20th and now it is broken again:
http://sourceware.org/ml/gdb-patches/2009-07/msg00504.html