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

[Eli Zaretskii <eliz@gnu.org>]

> 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 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?