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

[Hui Zhu <teawater@gmail.com>]

On Mon, Jun 15, 2009 at 01:43, Michael Snyder<msnyder@vmware.com> wrote:
> 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 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.  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.

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