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