stevens@uiucdcs.Uiuc.ARPA (08/02/85)
Does anyone have a method for writing out a core image of an executing job running under BSD 4.2 and later restoring the job to the state of execution prior to the save ? I have a routine that will do almost that but does not work 100 % of the time. It looks like there are pointers from the data area pointing into the system stack.. Does that make any sense? My solution appears to work fine if the core image is restored while still executing the original job. That is start a job.. do a save to a data file then continue executing.. then at some point do a restore from the data file and arrive back to the previous state of execution. The program in question which we would like to use this function on is a large 70,000 line pascal theorem prover. Currently the save/restore code is in C. Small test examples without dynamic memory allocation appear to work. Any suggestions or knowledge that the task is impossible would be welcome. Send replies via Arpanet to stevens@anl-mcs or simply reply to this notesfile. --Rick stevens@anl-mcs
ray@othervax.UUCP (Raymond D. Dunn) (08/09/85)
In article <39300040@uiucdcs> stevens@uiucdcs.Uiuc.ARPA writes: > >Does anyone have a method for writing out a core image of an executing >job running under BSD 4.2 and later restoring the job to the state of >execution prior to the save ? > Very interesting that this hasn't come up before (or has it?). It has always amazed me that this is not a standard feature of all operating systems, and I have had to implement various kludges over the years to enable checkpoint/restart capabilities. Please respond practically to the above request, but I would also like to see a philosophical discussion on the subject either here, with reference to UNIX, or elsewhere, in more general terms. Ray Dunn ..philabs!micomvax!othervax!ray "Excuse me, is this the room for an argument?" "I've told you once!"
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/10/85)
> Very interesting that this hasn't come up before (or has it?). It has > always amazed me that this is not a standard feature of all operating > systems, and I have had to implement various kludges over the years to > enable checkpoint/restart capabilities. Yes, it has come up several times. Nobody has answered the most fundamental objection, which is that the state of a process really includes the state of pipes to other processes, the state of the terminal, the state of files, etc. so that virtually the entire system would have to be checkpointed to provide a working general facility. There have been numerous attempts to checkpoint UNIX processes from user mode, but to do it right you would need the help of the kernel (since the code being checkpointed is still undergoing modification during the checkpoint process, otherwise). Apart from saving a bit of work in initializing large amounts of data, why do you feel this feature is necessary?
sean@ukma.UUCP (Sean Casey) (08/12/85)
How about gcore(1)?
--
- Sean Casey UUCP: sean@ukma.UUCP or
- Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean
- University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA preece@ccvaxa.UUCP (08/19/85)
> There have been numerous attempts to checkpoint UNIX processes from > user mode, but to do it right you would need the help of the kernel > (since the code being checkpointed is still undergoing modification > during the checkpoint process, otherwise). > Apart from saving a bit of work in initializing large amounts of data, > why do you feel this feature is necessary? /* Written 4:11 am Aug > 10, 1985 by gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn in ccvaxa:net.unix */ ---------- Sounds like enough reason in itself. Sometimes we're talking about LARGE amounts of data. The ability to start in the middle when doing something like starting nroff with a common macro set or starting Lisp after it has loaded all the stuff it does as start up, or starting a complex, extensible editor after it has already extended itself, would be very useful (I gather GNU emacs does just that). -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece