From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13979 invoked by alias); 13 Jun 2009 22:56:17 -0000 Received: (qmail 13969 invoked by uid 22791); 13 Jun 2009 22:56:17 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_05 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Jun 2009 22:56:09 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 8314E25061; Sat, 13 Jun 2009 15:56:05 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost2.vmware.com (Postfix) with ESMTP id 66A728E8DF; Sat, 13 Jun 2009 15:56:05 -0700 (PDT) Message-ID: <4A342EBB.4020601@vmware.com> Date: Sat, 13 Jun 2009 22:56:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Hui Zhu CC: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay. References: <83d4ane6kb.fsf@gnu.org> <833abiexcc.fsf@gnu.org> <83tz3ycchv.fsf@gnu.org> <83k54td2el.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-06/txt/msg00363.txt.bz2 Hui Zhu wrote: > Ping. OK, my bad for taking so long to get to this... please allow me to summarize the problem, to check my own understanding (tell me if I'm wrong). Currently linux-record.c does not know how to "undo" a sys_brk system call. You (teawater) are concerned because if the child process calls sys_brk to free some memory, we cannot un-free it and therefore we may get into trouble by writing to the freed memory during replay. Something like this: 1) child allocates memory X 2) child writes to memory X 3) child frees memory X 4) user asks for reverse-continue 5) gdb tries to revert the write that happened in step #2, gets SIGSEGV because location has been freed. So far so good? Now, your proposal is that during the record mode, we will detect any sys_brk call that frees memory, and query the user whether to continue or give up. I'm not too crazy about that solution. I think it's awkward, and drastic for a situation that may only be a problem later on (or not at all). Let me throw out some other ideas: A) Is it possible to actually "reverse" a sys_brk call? Suppose we record the arguments, and when we want to reverse it, we just change an increase into a decrease and vice versa? B) Suppose we wait until an actual memory error occurs during replay, and THEN inform the user? It will avoid warning him about something that may never happen. We could use catch_errors to trap the SIGSEGV, and then check to see if the error was caused by a write to memory above the BRK boundary. You will still need to keep track of the BRK boundary, but you won't have that awkward early query to deal with.