Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 exptools; site ihdev.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!ihdev!pdg From: pdg@ihdev.UUCP (P. D. Guthrie) Newsgroups: net.unix-wizards Subject: Re: Process Execution with Non-Standard Entry Points Message-ID: <496@ihdev.UUCP> Date: Thu, 30-Jan-86 11:04:38 EST Article-I.D.: ihdev.496 Posted: Thu Jan 30 11:04:38 1986 Date-Received: Sat, 1-Feb-86 01:27:38 EST References: <1867@brl-tgr.ARPA> <354@mcgill-vision.UUCP> Reply-To: pdg@ihdev.UUCP (55224-P. D. Guthrie) Organization: AT&T Bell Laboratories Lines: 29 In article <354@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP writes: > > Ptrace might be used to do this, but it can get awkward. I put >this in our kernel; it isn't very difficult (4.2bsd) if you have kernel >source. Unfortunately, you cannot have ANY files open at the time you >make the dump (open files looked like too much of a headache to save the >state of, so I let the programmer worry about closing and re-opening >files). It works OK; people here use it as a checkpoint mechanism for >programs which take cpu-hours or cpu-days. If anyone out there is >interested, mail me (see the .signature below) and I can give you >details, or if you have a source license we can work out something for >getting you the code. >-- Or of course if you know in advance what processes you want to do this to, simply write into the code a routine to dump all the info you want, assign it to a signal and just `kill' it from the shell. Much much easier. I used this on a process that soaked up excess CPU time (was running niced at +19) by calculating e, and when ever I wanted to get the current approximation, I sent SIGINT to it, and it made a file /usr/tmp/e with the current answer. This tecnique does not have anywhere near the flexability of some type of ptrace routine, but it is simple enough that I thought it worth mentioning. -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson