[Openmcl-devel] *initial-process* and *current-process*

[Gabriel Dos Reis]

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
> image/kernel
> from from which SAVE-APPLICATION was called:
>
> [src/oa.build-trunk-new] gb at rinpoche> md5sum src/boot/strap/bootsys
> src/lisp/lisp
> 6ab851c88925ba34b66ba381e1b17d4a  src/boot/strap/bootsys
> 6ab851c88925ba34b66ba381e1b17d4a  src/lisp/lisp
>
> That's pretty much exactly the behavior that you described (and which I've
> said/
> 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.

-- Gaby