1 ;;;; Dump the current Lisp image into a core file. Also contains
2 ;;;; various high-level initialization stuff: loading init files and
3 ;;;; parsing environment variables.
5 ;;;; (All the real work is done by C.)
7 ;;;; This software is part of the SBCL system. See the README file for
10 ;;;; This software is derived from the CMU CL system, which was
11 ;;;; written at Carnegie Mellon University and released into the
12 ;;;; public domain. The software is in the public domain and is
13 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
14 ;;;; files for more information.
16 (in-package "SB!IMPL")
18 ;;;; SAVE-LISP-AND-DIE itself
20 (define-alien-routine "save" (boolean)
22 (initial-fun (unsigned #.sb!vm:n-word-bits))
23 (prepend-runtime int))
26 (define-alien-routine "gc_and_save" void
28 (prepend-runtime int))
31 (defvar sb!vm::*restart-lisp-function*)
33 (defun save-lisp-and-die (core-file-name &key
34 (toplevel #'toplevel-init)
38 (environment-name "auxiliary")
41 "Save a \"core image\", i.e. enough information to restart a Lisp
42 process later in the same state, in the file of the specified name.
43 Only global state is preserved: the stack is unwound in the process.
45 The following &KEY arguments are defined:
48 The function to run when the created core file is resumed. The
49 default function handles command line toplevel option processing
50 and runs the top level read-eval-print loop. This function should
54 If true, arrange to combine the SBCL runtime and the core image
55 to create a standalone executable. If false (the default), the
56 core image will not be executable on its own.
59 If true (the default on cheneygc), do a purifying GC which moves all
60 dynamically allocated objects into static space. This takes
61 somewhat longer than the normal GC which is otherwise done, but
62 it's only done once, and subsequent GC's will be done less often
63 and will take less time in the resulting core file. See the PURIFY
64 function. For platforms that use the generational garbage collector
65 (x86 and x86-64) purification generally results in a loss of
69 This should be a list of the main entry points in any newly loaded
70 systems. This need not be supplied, but locality and/or GC performance
71 may be better if they are. Meaningless if :PURIFY is NIL. See the
75 This is also passed to the PURIFY function when :PURIFY is T.
78 The save/load process changes the values of some global variables:
80 *STANDARD-OUTPUT*, *DEBUG-IO*, etc.
81 Everything related to open streams is necessarily changed, since
82 the OS won't let us preserve a stream across save and load.
84 *DEFAULT-PATHNAME-DEFAULTS*
85 This is reinitialized to reflect the working directory where the
88 Foreign objects loaded with SB-ALIEN:LOAD-SHARED-OBJECT are automatically
89 reloaded on startup, but references to foreign symbols do not survive intact
90 on all platforms: in this case a WARNING is signalled when saving the core. If
91 no warning is signalled, then the foreign symbol references will remain
92 intact. Platforms where this is currently the case are x86/FreeBSD, x86/Linux,
93 x86/NetBSD, sparc/Linux, sparc/SunOS, and ppc/Darwin.
95 On threaded platforms only a single thread may remain running after
96 SB-EXT:*SAVE-HOOKS* have run. Applications using multiple threads can
97 be SAVE-LISP-AND-DIE friendly by registering a save-hook that quits
98 any additional threads, and an init-hook that restarts them.
100 This implementation is not as polished and painless as you might like:
101 * It corrupts the current Lisp image enough that the current process
102 needs to be killed afterwards. This can be worked around by forking
103 another process that saves the core.
104 * There is absolutely no binary compatibility of core images between
105 different runtime support programs. Even runtimes built from the same
106 sources at different times are treated as incompatible for this
108 This isn't because we like it this way, but just because there don't
109 seem to be good quick fixes for either limitation and no one has been
110 sufficiently motivated to do lengthy fixes."
112 ;; FIXME: Would it be possible to unmix the PURIFY logic from this
113 ;; function, and just do a GC :FULL T here? (Then if the user wanted
114 ;; a PURIFYed image, he'd just run PURIFY immediately before calling
115 ;; SAVE-LISP-AND-DIE.)
116 (labels ((restart-lisp ()
117 (handling-end-of-the-world
123 ;; Do a destructive non-conservative GC, and then save a core.
124 ;; A normal GC will leave huge amounts of storage unreclaimed
125 ;; (over 50% on x86). This needs to be done by a single function
126 ;; since the GC will invalidate the stack.
127 #!+gencgc (gc-and-save (unix-namestring core-file-name nil)
128 (if executable 1 0)))
130 (save (unix-namestring core-file-name nil)
131 (get-lisp-obj-address #'restart-lisp)
132 (if executable 1 0)))))
133 ;; Save the restart function into a static symbol, to allow GC-AND-SAVE
134 ;; access to it even after the GC has moved it.
136 (setf sb!vm::*restart-lisp-function* #'restart-lisp)
138 (purify :root-structures root-structures
139 :environment-name environment-name)
142 ;; Compact the environment even though we're skipping the
143 ;; other purification stages.
144 (sb!kernel::compact-environment-aux "Auxiliary" 200)
148 (dolist (hook *save-hooks*)
149 (with-simple-restart (continue "Skip this save hook.")
151 (when (rest (sb!thread:list-all-threads))
152 (error "Cannot save core with multiple threads running."))
154 (when (fboundp 'cancel-finalization)
155 (cancel-finalization sb!sys:*tty*))