This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
industrial use of 'record' and replay.
- From: Edward Peschko <horos11 at gmail dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 2 Jun 2009 14:48:47 -0700
- 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?
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