RE: industrial use of 'record' and replay.

["Marc Khouzam" <marc.khouzam@ericsson.com>]

 

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