Re: [RFC] a prototype checkpoint-restart using core files

[Michael Snyder <michsnyd@cisco.com>]

Mark Kettenis wrote:
>>Date: Mon, 07 Nov 2005 06:40:22 +0200
>>From: Eli Zaretskii <eliz@gnu.org>
>>
>>>Date: Sun, 6 Nov 2005 19:19:37 -0500
>>>From: Daniel Jacobowitz <drow@false.org>
>>>Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
>>>
>>>I've got to say that this is amazingly cool.
>>>
>>>Afraid that's all the comments I have time for at the moment :-)
>>
>>I agree, and I'd add that getting this into GDB soon would be good.
> 
> 
> 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 :(.

Yes, I'm still puzzling over that one.  However, it would
mostly only happen (sic) if you are going forward in time,
not backward.  In particular, if you create a new process,
then try to feed it a corefile from an old process that
was further along in its execution.

If you save a gcore file, run forward, and then reload
the previously saved gcore file back into the *same* process
(ie. go backward in time), the mmaped areas will almost
always be present -- unles someone explicitly unmaps them.

As for your broader point, I agree, I don't think this is
ready for exposure to average users.  I would like to see
it get some play from "sophisticated" users such as you
guys, who may understand the limitations and help to
characterize them.