This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] a prototype checkpoint-restart using core files
Daniel Jacobowitz wrote:
On Mon, Nov 07, 2005 at 07:57:25PM +0100, Mark Kettenis wrote:
Heh, I'd expected Eli to ask for documentation ;-)
Anyway, in this cause I think that's important since I expect a lot of
users won't understand its limitations.
If I read the code correctly, there is one rather serious limitation
though: restoring mmapped area's will fail if the same area isn't
mapped in the target process. Especially on systems that randomize
the location of mmapped memory this will make the usefullness of this
feature pretty limited :(.
Why should it? The expected use is to restore these dumps into the
same running session - just after stepping a bit. So unless you step
across a very large free(), it should be fine.
I admit the general-purpose rcore command has a lot of limitations, but
not as part of a checkpoint-restart system.
Yes, the next interesting task (before publication, I should think)
is to characterize and refine those limitations. Experimentally,
I have found that I can jump backward across many system calls,
but not all. I'd like to work on some idea of which ones are
always ok, which ones are sometimes ok, and which ones will never
be ok.
For instance, I wrote a simple test program that copies stdin
to stdout, one byte at a time, in a loop. I ran it with input
and output redirected (so that it copies a file). I checkpointed
it near the beginning, let it run thru 20,000 loops, then went
back to the checkpoint -- and then ran it to completion (so that
the first 20,000 bytes were copied twice). The resulting input
and output files compared identical.
But when i repeated the experiment, but jumped backward across
50,000 loops, the output file was corrupted.
This is just a crude shot-in-the-dark experiment, obviously;
but it tends to show that we can get away with somewhat more
than we might at first suppose.
[this was ix86-linux native]