From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12883 invoked by alias); 7 Nov 2005 19:50:47 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 12858 invoked by uid 22791); 7 Nov 2005 19:50:45 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 07 Nov 2005 19:50:45 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 11:50:43 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="672500995:sNHT25545012" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA7JoKKS027822; Mon, 7 Nov 2005 11:50:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:50:39 -0800 Received: from [128.107.165.67] ([128.107.165.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:50:38 -0800 Message-ID: <436FB00E.40306@cisco.com> Date: Mon, 07 Nov 2005 19:50:00 -0000 From: Michael Snyder User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] a prototype checkpoint-restart using core files References: <43696953.9090601@cisco.com> <20051107001937.GG19200@nevyn.them.org> <200511071857.jA7IvP4K005599@elgar.sibelius.xs4all.nl> <20051107190724.GA19531@nevyn.them.org> In-Reply-To: <20051107190724.GA19531@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00160.txt.bz2 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]