From owner-freebsd-questions Mon Dec 18 13:58:26 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA22334 for questions-outgoing; Mon, 18 Dec 1995 13:58:26 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22327 for ; Mon, 18 Dec 1995 13:58:17 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA24671; Mon, 18 Dec 1995 14:59:05 -0700 Date: Mon, 18 Dec 1995 14:59:05 -0700 From: Nate Williams Message-Id: <199512182159.OAA24671@rocky.sri.MT.net> To: Terry Lambert Cc: hlew@genome.Stanford.EDU (Howard Lew), questions@FreeBSD.org Subject: Re: undump program In-Reply-To: <199512182105.OAA12378@phaeton.artisoft.com> References: <199512182105.OAA12378@phaeton.artisoft.com> Sender: owner-questions@FreeBSD.org Precedence: bulk > > Actually, I think a better question would be.... Is there an undump > > program to take a core dump and run it? > > Core dumps wouldn't be core dumps if they were runnable. Unless you specifically designed your program to dump core and be ran afterward. ;) > The big problem with a core dump is that the condition that caused the > dump to occur exists in the state of the dump as an imminent problem > after an undump. > > The next big problem is that you can't reopen the fd's associated with > the fd's the process had open, since they file names aren't part of > the state information. Don't do anything in your program which has to be re-run everytime the program is re-started. FWIW, the original 386bsd->FreeBSD 1.0 upgrade script consisted of two un-dumped perl scripts. It was easier to provide a binary which did the upgrade rather than provide perl and the script both, so I had perl dump core and then found a version of undump on the net and compiled it for FreeBSD. However, that was 2 years ago, so I doubt I'd be able to find it. However, you might try archie or lycos and see if you can find it. Nate