save-lisp-and-die and open file descriptors

[Tobias C. Rittweiler]

TFB on comp.lang.lisp

> Squeak tries to reopen the resources you left open when you saved the
> image. A questionable feature, if you ask me -- I'd rather just get an
> error if you try to access a server socket or open file that survived
> a dump/reload. Of course, Squeak's behavior is better than the third
> option, which is what at least SBCL and Allegro do: they dump streams
> referencing file descriptors by number. Try this for example:
>
> $ sbcl
> * (defvar *s* (open ".bashrc"))
> * (save-lisp-and-die "/tmp/sbcl.core")
> $ sbcl --core /tmp/sbcl.core
> * (open ".emacs")
> * (read-line *s*)
>
> You'll get the first line of your .emacs file. Mutatis mutandis,

I'm surprised by this behaviour. For a start, it's not documented.

Not that I'd have expected it to work, but I think the documentation
should make it more clear. In particular, it should state that
SAVE-LISP-AND-DIE should most probably be used directly from a fresh
sbcl toplevel just after having loaded in all the stuff one wants in
the image.

Of course, extra kudos for dealing with this issue.

[Douglas Katzman (dougk)]

Users should not expect any particular behavior in regard to open streams, and I don't see that particular result. Instead I see an error:
* (read-line *s*)

debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread
#<THREAD "main thread" RUNNING {10004C85B3}>:
  couldn't read from #<SB-SYS:FD-STREAM for "file /usr/local/google/home/dougk/.emacs" {1000C82493}>:
    Bad address

I'll grant that the error was random: the read call attempted to use a buffer that was allocated in foreign memory in the image that did the saving, and there was no memory at that address in the second process. Seems pretty reasonable to me. There _could_ have been memory there, but honestly the same issue crops up in 3rd-party libraries: they save SAPs into a core. Just don't do that.

[Stas Boukarev (stassats)]

With c0fd1f0b49ac098b8733fd9c5fe134c1f0626755