From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24234 invoked by alias); 14 Jun 2009 09:26:09 -0000 Received: (qmail 24225 invoked by uid 22791); 14 Jun 2009 09:26:09 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f196.google.com (HELO mail-pz0-f196.google.com) (209.85.222.196) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 14 Jun 2009 09:26:02 +0000 Received: by pzk34 with SMTP id 34so1275930pzk.12 for ; Sun, 14 Jun 2009 02:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.212.21 with SMTP id k21mr2154039wfg.250.1244971560665; Sun, 14 Jun 2009 02:26:00 -0700 (PDT) In-Reply-To: <4A342EBB.4020601@vmware.com> References: <833abiexcc.fsf@gnu.org> <83tz3ycchv.fsf@gnu.org> <83k54td2el.fsf@gnu.org> <4A342EBB.4020601@vmware.com> Date: Sun, 14 Jun 2009 09:26:00 -0000 Message-ID: Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay. From: Hui Zhu To: Michael Snyder Cc: Eli Zaretskii , "gdb-patches@sourceware.org" 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-06/txt/msg00368.txt.bz2 On Sun, Jun 14, 2009 at 06:56, Michael Snyder wrote: > 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). > For that "nice people" words. I just want to make a joke. :) > Currently linux-record.c does not know how to "undo" a sys_brk > system call. =A0You (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. =A0Something like this: > > =A01) child allocates memory X > =A02) child writes to memory X > =A03) child frees memory X > =A04) user asks for reverse-continue > =A05) gdb tries to revert the write that happened in step #2, > =A0 =A0 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. =A0I think it's > awkward, and drastic for a situation that may only be > a problem later on (or not at all). =A0Let 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? =A0It 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. =A0You will still need to keep track > of the BRK boundary, but you won't have that awkward early > query to deal with. The sys_brk just can increase and decrease data segment size. The decrease behavior is very hard to replay. I read some code of malloc and free in glibc. I found that most of time, free will not call brk to release memory to system. Because it is low efficiency. So I think when brk release really happen, give user a query is a easy way to handle it. What do you think about it? thanks, Hui