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

[Hui Zhu <teawater at gmail dot 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