This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

    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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]