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

[Hui Zhu <teawater at gmail dot com>]

On Thu, May 7, 2009 at 02:28, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 6 May 2009 11:35:38 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
>>
>> On Wed, May 6, 2009 at 11:14, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Wed, 6 May 2009 10:13:15 +0800
>> >> From: Hui Zhu <teawater@gmail.com>
>> >> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
>> >>
>> >> If inferior release some memory, the replay will got big error because
>> >> prec will set memory old value to this memory.
>> >
>> > Yes, I understand that, but why will this cause an error?
>>
>> If this memory already release and gdb still write value to this
>> address, ?the os mm will make this operation fail.
>
> Why would GDB write to the memory that no longer belongs to the
> inferior? ?Are you talking about GDB in general or process
> record/replay in particular? ?If the former, I'd say that's a bug. ?If
> the latter, when and under what conditions will record/replay need to
> do that?
>
> I thought the problem was that replaying the execution log before the
> sbrk point would be impossible, because (I thought) there's no way of
> regaining back the memory the inferior gave up. ?Is this the problem
> you are talking about? ?If so, that is not a fatal limitation, and it
> certainly does not justify stopping the program and asking the user to
> make some grave decision. ?The user just needs to be notified, when
> she tries that, that she cannot reverse-replay the log past this
> point. ?If the user never tries to replay past that point, she never
> needs to know about the problem.

I am not sure make inferior cannot continue is good or not.  I think
let user choice continue or stop is better.



>
>> I think both reinitialize and prepare is OK for me. ?Do you have some
>> idea with it?
>
> I can live with both. ?What do others think?
>