From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23696 invoked by alias); 7 May 2009 02:21:14 -0000 Received: (qmail 23678 invoked by uid 22791); 7 May 2009 02:21:12 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.190) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 May 2009 02:21:07 +0000 Received: by ti-out-0910.google.com with SMTP id a1so36024tib.12 for ; Wed, 06 May 2009 19:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.8.5 with SMTP id 5mr132903tih.4.1241662864247; Wed, 06 May 2009 19:21:04 -0700 (PDT) In-Reply-To: <83tz3ycchv.fsf@gnu.org> References: <83d4ane6kb.fsf@gnu.org> <833abiexcc.fsf@gnu.org> <83tz3ycchv.fsf@gnu.org> Date: Thu, 07 May 2009 02:21:00 -0000 Message-ID: Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay. From: Hui Zhu To: Eli Zaretskii Cc: gdb-patches@sourceware.org, msnyder@vmware.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-05/txt/msg00144.txt.bz2 On Thu, May 7, 2009 at 02:28, Eli Zaretskii wrote: >> Date: Wed, 6 May 2009 11:35:38 +0800 >> From: Hui Zhu >> Cc: gdb-patches@sourceware.org, msnyder@vmware.com >> >> On Wed, May 6, 2009 at 11:14, Eli Zaretskii wrote: >> >> Date: Wed, 6 May 2009 10:13:15 +0800 >> >> From: Hui Zhu >> >> Cc: gdb-patches@sourceware.org, msnyder@vmware.com >> >> >> >> If inferior release some memory, the replay will got big error because >> >> prec will set memory old value to this memory. >> > >> > Yes, I understand that, but why will this cause an error? >> >> If this memory already release and gdb still write value to this >> address, =A0the os mm will make this operation fail. > > Why would GDB write to the memory that no longer belongs to the > inferior? =A0Are you talking about GDB in general or process > record/replay in particular? =A0If the former, I'd say that's a bug. =A0If > the latter, when and under what conditions will record/replay need to > do that? > > I thought the problem was that replaying the execution log before the > sbrk point would be impossible, because (I thought) there's no way of > regaining back the memory the inferior gave up. =A0Is this the problem > you are talking about? =A0If so, that is not a fatal limitation, and it > certainly does not justify stopping the program and asking the user to > make some grave decision. =A0The user just needs to be notified, when > she tries that, that she cannot reverse-replay the log past this > point. =A0If the user never tries to replay past that point, she never > needs to know about the problem. I am not sure make inferior cannot continue is good or not. I think let user choice continue or stop is better. > >> I think both reinitialize and prepare is OK for me. =A0Do you have some >> idea with it? > > I can live with both. =A0What do others think? >