Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.unix.questions Subject: Re: Core files ... still trying Keywords: core Message-ID: <537@philmds.UUCP> Date: 28 Jun 88 21:31:55 GMT References: <344@ajpo.sei.cmu.edu> <441@anagld.UUCP> <790@scubed.UUCP> <11954@mimsy.UUCP> <796@scubed.UUCP> Reply-To: leo@philmds.UUCP (L.J.M. de Wit) Organization: Philips I&E DTS Eindhoven Lines: 55 In article <796@scubed.UUCP> warner@scubed.UUCP (Ken Warner) writes: |In article <11954@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: ||In article <790@scubed.UUCP> warner@scubed.UUCP (Ken Warner) writes: |||Is there a way to run a core file? || ||It cannot be done portably, but with certain restrictions, it can ||almost always be done. |[stuff deleted] ||-- ||In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) ||Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris | |Well, I've looked at unexec() from emacs and then tried to write my own version |of a fuction that will create a new executable, saving the current data space. |It does work (sort of), but when the new executable is run, a segmentation |violation occurs in the clean up on exit. I dunno how to deal with this. |Anyone care to comment? Below is a stack trace from dbx showing the error. |Below that is the fuction I've been working with. | |Basically, the function (my)unexec() copies the text segment from the |executable file since that won't be changing, then copies the data segment |from memory. Then copies the symbol table and string table from the executable |file. The result is an executable with a snapshot of the data segment. Like |I said, it runs but dies a horrible death on exit. ut.c was the name of |my main(). You do not copy the BSS space nor any extension of the data space (caused by sbrk's). This may just be your problem. If any dynamic allocation has been done (using malloc, calloc, sbrk etc.) for instance for FILE buffers, or even for FILE struct's (BSD for instance allocates dynamically all FILE structs except for the 3 standard static ones) problems are to be expected. The trouble could be that when _fwalk closes files, it tries to free buffers residing in a space you should have included with you copy. But of course you cannot include a BSS in your executable; so possibly the best tactic is to avoid using stdio before the executable is written to avoid buffer creation. This can be more tricky than you think; even function as getlogin() use it. I'm still wondering why you use 1 char writes? Pretty expensive I think. And I also would like to know what use this scheme has? Is it for speedup of programs that do a lot of processing, table creation and the like before actually taking off? Then I've got an alternative: write out the complete data space, and when you start up again, sbrk to the correct position (derivable from the datafile's size and the current breakpoint) and read it in. I've used it with a rapid prototyping system that always created parse tables, even if the source program text hadn't changed. The creation of tables that first took several minutes now only takes about 4 seconds. The only problem I had with some variables that point into a different space, for instance environ in the BSS that points to the stack. Just saving before and restoring after the read of the datafile solved this. Leo.