Re: industrial use of 'record' and replay.

[Hui Zhu <teawater@gmail.com>]

On Wed, Jun 10, 2009 at 03:39, Toby Haynes<thaynes@ca.ibm.com> wrote:
>> Edward Peschko <horos11@gmail.com>
>> What I want to do is record a program, but not necessarily have to
> replay it
>> from the start of its recording - ie: have the system automatically
>> take 'snapshots'
>> of the state at given intervals, and then have the ability to replay
>> from any given
>> snapshot.
>
> Picking up on this, is it possible to configure the record to use a
> circular buffer, effectively recording only the most recent events? Even
> better if we can specify the size or number of events on that buffer.
>
> If, for example, I wanted to use this to debug a crash problem in a large
> project (where large implies more than 1Gb of source code, with multiple
> processes and threads), being able to set reasonable bounds for recording
> will be critical to make use of this facility. Doubly so in scenarios
> which fail stress tests after more than 24 hours of operation. Being able
> to rewind from the crash point to see precisely what lead to the crash
> would be a killer feature, with huge time savings.
>

I think implement a circular buffer is very hard to precord.  Because
precord need the all the memory of inferior.
But I have another idea to implement the example:
Set 1 breakpoint at the begin of code that you want record and use
"commands" let precord begin work at there.
Set another breakpoint at the end of code that you want record and use
"commands" gcore, dump record message, stop record.
Then, when you want analyze the bug of this code, you can use the core
file(It will help prec get inferior memory) and record dump message to
do it.

Now, prec still not support dump record message and multi-thread.  I
am dealing with them.


Thanks,
Hui