On Sun, Jan 27, 2002 at 12:02:17AM +0000, Christophe Rhodes wrote:
> On Sat, Jan 26, 2002 at 01:35:08AM +0000, Daniel Barlow wrote:
> > It compiles, it builds PCL, it purifies, it save-lisp-and-dies, it
> > passes all tests but for three (foreign.test, irrat.pure,
> > run-program.test).
> And warm on Dan's heels, I can report that the SPARC port is likewise
> in pretty decent shape -- many thanks to the patient denizens on
> #lisp@... for putting up with questions about
> SPARC assembly, the Linux kernel, and all sorts of other things not
> directly related to lisp. Particular thanks, of course, to Dan Barlow
> for much patient teaching.
> Wheeeeeeeeeeeeeee! It works!
> There is a certain amount of cleaning up that needs to be done,
> certainly in my tree, as well as the forward port to 0.7. One thing
> that I have discovered, which casued me a little pain when debugging,
> was that there is no barrier at the end of read-only-space; sbcl will
> happily scribble over the end. This causes all sorts of problems, as
> various get_bad_addr -type functions assume that the end of read-only
> space is where it says it is; for a long while, I had
> READ_ONLY_SPACE_START == READ_ONLY_SPACE_END, with hilarious
> results. Similarly, when my read-only-space was insufficiently big,
> purify died with a sigsegv in the GC phase, which wasn't the clearest
> indication of the problem.
Patches to add safeguards and sanity checks for memory issues like
this would be welcome, at least as long as they're not too complicated
or flaky-looking. The fewer places where angels fear to tread, the
better, sez I. (Though, on a related issue, what I'd *really* like to
have would be safeguards for user level memory problems, e.g. some way
to recover gracefully from stack or heap overflow in a user program.)
William Harold Newman <william.newman@...>
"Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C