Core files ... still trying

[Leo de Wit]

In article <796 at scubed.UUCP> warner at scubed.UUCP (Ken Warner) writes:
|In article <11954 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
||In article <790 at scubed.UUCP> warner at 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 at 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.