[Openmcl-devel] *initial-process* and *current-process*
Gabriel Dos Reis
gdr at open-axiom.net
Fri Jun 24 18:38:09 CDT 2011
On Fri, Jun 24, 2011 at 3:16 PM, Gary Byers <gb at clozure.com> wrote:
> Well, I think that I have a partial explanation for the mystery. I said the
> other day that SAVE-APPLICATION wouldn't write a partial image: if it erred
> before writing the full image to disk, the result wouldn't be loadable.
> That's true up to a point ...
> (SAVE-APPLICATION output :PREPEND-KERNEL T) works by finding the file
> containing the running kernel, copying that file to the "output"
> pathname. If the kernel contains an embedded heap image (if it was
> the result of a previous SAVE-APPLICATION call with :PREPEND-KERNEL,
> that embedded image (from the running kernel) is copied to the output
> file; the intent is that the file will be truncated (so that the
> embedded image isn't present) at a slightly later point in time.
> The short version of what happens next is that (because of a post-1.6
> change in the trunk) we never reach that later point in time because
> something calls CCL:QUIT with a default exit status of 0. We never
> get around to truncating the file and never actually write the current
> heap contents to the output file; it's entirely identical to the
> from from which SAVE-APPLICATION was called:
> [src/oa.build-trunk-new] gb at rinpoche> md5sum src/boot/strap/bootsys
> 6ab851c88925ba34b66ba381e1b17d4a src/boot/strap/bootsys
> 6ab851c88925ba34b66ba381e1b17d4a src/lisp/lisp
> That's pretty much exactly the behavior that you described (and which I've
> been thinking was impossible.)
> There are at least two bugs there: the call to QUIT was coming from the
> (modified) code to handle a user-supplied toplevel-function. It makes
> some sense to ensure that QUIT is called if that function just returns,
> but this was happening even if the thread was being killed. We also
> really, really don't want the copied executable image to "look valid"
> at this point: if we don't get around to truncating it and writing
> current heap contents to the file, it shouldn't look like a valid image.
> I think that the first of these is fixed in r14849; I made that change
> and then tried "make' instead of "make all-boot" and it's been running
> for quite a while now ...
Thanks for the detective work and the fix! Yes, it is a good news that
it has been running for quite a while :-) I concur that I have a successful
build with newest CCL trunk on x86-64.
More information about the Openmcl-devel