Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay.

[Michael Snyder <msnyder at vmware dot com>]

Hui Zhu wrote:
> On Sun, Jun 14, 2009 at 06:56, Michael Snyder<msnyder@vmware.com> 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.  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.
>
> The sys_brk just can increase and decrease data segment size.  The
> 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 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?

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.  At 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:

   1) Remember the BRK boundary at start (as you do in this patch).
   2) Remember the new BRK boundary whenever it changes (as you do).
   3) During replay, compare every memory write against the BRK
boundary.  If the memory write will fail because it is above the
BRK boundary, stop and inform the user that we cannot go back
any further.