Problems in TOPS-10 MACLISP

[Scott.Fahlman at CMU-10A (C380SF50)]

Hi,
We're having lots of problems with relatively simple bugs that, instead
of trapping back to MACLISP, cause the LISP to flame out to the TOPS-10
monitor.  In particular, things like SETQ'ing NIL and FASLOADing too
much into the fixed BPS allocation cause a fatal trap back to the system.
Which makes it hard to debug the losing code.  I seem to recall that there
is a way in TOPS to get hold of such errors in the user program, and I think
I remember some code in the MACLISP source listing that claimed to be for
this purpose, but either I was hallucinating (I can't find it now) or it
is busted.  Anyway, if it's a relatively easy fix it is something that we
really could use.

We're also having a weird problem with RENAMEF clobbering things that it
should have no way of getting at, like the CDR of a list that is being
MAPCARed, with the car eventualy going to RENAMEF.  It looks like it's
clobbering something on the stack or the contents of a register or something
of the sort.  Sorry I can't be clearer about the problem -- we're trying
to get a nice clean case to send you, but it seems to show up only within
certain hairy functions we've written (Touretzky's SLURP package).  When
we get a clean form of the bug we'll send it.  In the meantime, if anything
occurs to you (as in "Oh yeah, the old RENAMEF bug is back") we'd like to
hear about it.

Thanks,
Scott Fahlman