From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28449 invoked by alias); 6 May 2009 18:28:39 -0000 Received: (qmail 28439 invoked by uid 22791); 6 May 2009 18:28:38 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 18:28:33 +0000 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KJ800H00J9X2700@i_mtaout5.012.net.il> for gdb-patches@sourceware.org; Wed, 06 May 2009 21:28:05 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.230.216]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KJ800J80JAKHMA1@i_mtaout5.012.net.il>; Wed, 06 May 2009 21:28:05 +0300 (IDT) Date: Wed, 06 May 2009 18:28:00 -0000 From: Eli Zaretskii Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay. In-reply-to: To: Hui Zhu Cc: gdb-patches@sourceware.org, msnyder@vmware.com Reply-to: Eli Zaretskii Message-id: <83tz3ycchv.fsf@gnu.org> References: <83d4ane6kb.fsf@gnu.org> <833abiexcc.fsf@gnu.org> 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/msg00129.txt.bz2 > 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, the os mm will make this operation fail. Why would GDB write to the memory that no longer belongs to the inferior? Are you talking about GDB in general or process record/replay in particular? If the former, I'd say that's a bug. If 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. Is this the problem you are talking about? If 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. The user just needs to be notified, when she tries that, that she cannot reverse-replay the log past this point. If the user never tries to replay past that point, she never needs to know about the problem. > I think both reinitialize and prepare is OK for me. Do you have some > idea with it? I can live with both. What do others think?