From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24897 invoked by alias); 14 Sep 2009 17:19:02 -0000 Received: (qmail 24881 invoked by uid 22791); 14 Sep 2009 17:19:01 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 17:18:56 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8EHIpjY031283; Mon, 14 Sep 2009 12:18:53 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 12:18:51 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 12:18:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Sep 2009 13:18:50 -0400 From: Marc Khouzam To: "'Greg Law'" , "'Hui Zhu'" CC: "'gdb@sourceware.org'" , "'Michael Snyder'" , "'gdb-patches ml'" Date: Mon, 14 Sep 2009 17:19:00 -0000 Subject: RE: PRecord sets memory even when it says it did not Message-ID: References: <4AAE7910.5040907@undo-software.com> In-Reply-To: <4AAE7910.5040907@undo-software.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00415.txt.bz2 > -----Original Message----- > From: Greg Law [mailto:glaw@undo-software.com]=20 > 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 >=20 ... >=20 > I've noticed something similar with UndoDB. Until very=20 > 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=20 > (as of about=20 > two weeks ago), despite UndoDB failing the poke, the value=20 > still appears > to the user to have been written. >=20 > 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