industrial use of 'record' and replay.

industrial use of 'record' and replay.

[Edward Peschko]

All,

First of all, I'm really glad to see that record and replay is going to make
it into gdb. Predictions aren't easy here, but my guess is that it is going to
revolutionize debugging..

However, I had a few questions, about 'scaling up' the use of this:

    1. Suppose that one has an extremely long process, one which takes hours to
        'get' to the bug.. How can one 'short circuit' this process so
that you don't need
        to replay for hours to get to it?

    2. Suppose that one has a test suite, one that runs a command - or series of
        commands - multiple times. How does one save states of
'interest', ones that
        cause segfaults or deadlocks?

    3. Suppose that one is testing something like a server, one that
has multiple
        processes.. is there a way to 'record' without running under
gdb, or to record
        sub processes as via strace or truss?

I'm sure I'll have more as I start using it, but any ideas on the
above would be
very helpful..

Ed

RE: industrial use of 'record' and replay.

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Edward Peschko
> Sent: June-02-09 5:49 PM
> To: gdb@sourceware.org
> Subject: industrial use of 'record' and replay.
> 
> All,
> 
> First of all, I'm really glad to see that record and replay 
> is going to make
> it into gdb. Predictions aren't easy here, but my guess is 
> that it is going to
> revolutionize debugging..
> 
> However, I had a few questions, about 'scaling up' the use of this:
> 
>     1. Suppose that one has an extremely long process, one 
> which takes hours to
>         'get' to the bug.. How can one 'short circuit' this process so
> that you don't need
>         to replay for hours to get to it?

I'm not sure I understand.
Do you want to avoid the 'long execution' all together or do you want
to avoid executing it with Recording enabled?  Can you predict about
where in the program the bug occurs?

Without fully understanding the question, some things that do come to 
mind that might be relevant are:

o GDB checkpoints (look for the chapter on bookmarks)
o only turning on Record once you are close to the bug, instead
   of turning it on from the start
o setting the program counter to a new address to literally skip
   a large part of the execution 

>     2. Suppose that one has a test suite, one that runs a 
> command - or series of
>         commands - multiple times. How does one save states of
> 'interest', ones that
>         cause segfaults or deadlocks?

Do you mean 'save to file', so as to use later?
That would be cool.  I don't think this exists for PRecord
or for Checkpoints (maybe I'm wrong?), but it would be a nice
feature.

> 
>     3. Suppose that one is testing something like a server, one that
> has multiple
>         processes.. is there a way to 'record' without running under
> gdb, or to record
>         sub processes as via strace or truss?
> 
> I'm sure I'll have more as I start using it, but any ideas on the
> above would be
> very helpful..
> 
> Ed
> 

Re: industrial use of 'record' and replay.

[Edward Peschko]

>> However, I had a few questions, about 'scaling up' the use of this:
>>
>>     1. Suppose that one has an extremely long process, one
>> which takes hours to
>>         'get' to the bug.. How can one 'short circuit' this process so
>> that you don't need
>>         to replay for hours to get to it?
>
> I'm not sure I understand.
> Do you want to avoid the 'long execution' all together or do you want
> to avoid executing it with Recording enabled?  Can you predict about
> where in the program the bug occurs?

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.

Since this would be used in a test suite, I'd like it to be
automatable, ie: set up
in a config file, and then run without any interaction with the user.
One could then
run the test suite, and in the case of 'interesting events' take the
latest version
of the snapshot and run it from that point (rather than from the
beginning of the run,
which may be hours before). If the 'true' bug lies before the latest
snapshot, go
back to the previous snapshot (and the one previous) until the bug
itself is found.

Anyways, looking at your reply and reading about checkpoints, I'm not
sure if they
apply here. Maybe someone more familiar with the internals of record/replay can
comment..

Thanks much,

Ed

Re: industrial use of 'record' and replay.

[Toby Haynes]

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

Thanks,
Toby Haynes

Re: industrial use of 'record' and replay.

[Hui Zhu]

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