>>>>> "wb" == William Brew <[EMAIL PROTECTED]> writes:
wb> In 18e, whenever we tried saving with :purify t (the default),
wb> cmucl dumped core. We progressed by just specifying :purify nil.
wb> This appeared to work fine in 18e and 2003_12. In 2004_04, this
wb> approach saves a lisp core but when you start the core, you get
wb> a div by 0 error before lisp even has a chance to print the
wb> herald.
I can reproduce this on Sparc; it looks like it's due to a false
assumption in VOLATILE-INFO-LOOKUP. I'm rebuilding to see whether my
simple fix is sufficient.
wb> In 18e, using purify fails on our application Ditto in 2003_12.
wb> Ditto in 2004_04. The failure mode is a core dump. The heap size
wb> is around 53Mbyte.
from your transcript, it looks like you are loading 3 foreign object
files using EXT:LOAD-FOREIGN. You should not expect these objects to
be reloaded correctly when restarting a dumped core, and the
symptoms could indeed be a core dump.
Assuming that these are shared libraries, could you try using
SYS::LOAD-OBJECT-FILE instead of LOAD-FOREIGN, and say
(pushnew 'sys::reinitialize-global-table ext:*after-save-initializations*)
before saving your lisp. This only has a chance of working in the
2004-04 snapshot, otherwise you can try the code in
http://article.gmane.org/gmane.lisp.cmucl.general/2401
wb> Related to the purify problem, I attempted to duplicate the
wb> purify problem outside the context of our application. I created
wb> a program that just consed up a bunch of arrays and then tried
wb> to do a purify. There is some fog here. In 2003_12, with a
wb> particular set of size parameters you get a segmentation
wb> violation.
I can reproduce this too, on both Sparc and Linux/x86, when the size
parameters are increased. I don't know what the cause is.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
