From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14027 invoked by alias); 15 Jun 2009 08:04:14 -0000 Received: (qmail 13828 invoked by uid 22791); 15 Jun 2009 08:04:13 -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; Mon, 15 Jun 2009 08:04:07 +0000 Received: by pzk34 with SMTP id 34so1674597pzk.12 for ; Mon, 15 Jun 2009 01:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.14.18 with SMTP id 18mr2856651wfn.304.1245053045025; Mon, 15 Jun 2009 01:04:05 -0700 (PDT) In-Reply-To: <4A3536B8.1090508@vmware.com> References: <83tz3ycchv.fsf@gnu.org> <83k54td2el.fsf@gnu.org> <4A342EBB.4020601@vmware.com> <4A3536B8.1090508@vmware.com> Date: Mon, 15 Jun 2009 08:04: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/msg00380.txt.bz2 On Mon, Jun 15, 2009 at 01:43, Michael Snyder wrote: > Hui Zhu wrote: >> >> 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. =A0I just want to make a joke. =A0:) >> >>> 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 =A0gets 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. =A0The >> decrease behavior is very hard to replay. > > I admit my ignorance in this area, but why is it difficult? > In my simple-minded view, if we need to reverse over a sys_brk > decrease call, we just make an increase call in the same amount. > > Please tell me what I am missing. > I think about it again. Maybe let it increase and decrease can handle this issue. But call function when infrun is running is a very hard job. Because call_function_by_hand will clear a lot of thing of inferior. We can do it. But it must need a long time to check in. So maybe we can give user a warning first. >> I read some code of malloc and free in glibc. =A0I found that most of >> time, free will not call brk to release memory to system. =A0Because 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? > > OK, assuming that we cannot actually reverse the call, I agree > that we may encounter a situation where we cannot go back any > further -- but I think we should wait until we actually encounter > that situation before we notify the user. > > During record phase is too early for that notification. > The actual failure may never be encountered, especially if > the user never tries to reverse past this point in the recording. > > What I think is that we should wait until we are replaying, and > we actually experience a failure to modify freed memory. =A0At that > point we tell the user what has happened, and explain that we > cannot go back any earlier in the recording. > > So something like this: > > =A0 1) Remember the BRK boundary at start (as you do in this patch). > =A0 2) Remember the new BRK boundary whenever it changes (as you do). > =A0 3) During replay, compare every memory write against the BRK > boundary. =A0If the memory write will fail because it is above the > BRK boundary, stop and inform the user that we cannot go back > any further. It will make user lost the record entry that before this memory operation. And when this thing happen (sys_brk), user doesn't get any alert. Thanks, Hui