bug in GC

[Dave Touretzky at CMU-10A]

The following bug appears in the Tops-10, Tops-20, and ITS versions
of MacLisp.  A rather simple user program is having its arrays
munged immediately after the first garbage collection takes place.

To demonstrate the bug, retrieve file MOVEIT.MCL[C410DT50] from CMUA,
and also file BUG.INI[C410DT50].  Start up a lisp, feed it BUG.INI as
the init file, and let the program run for 1-2 minutes.  It eventually
prints some asterisks and the message "Something is rotten in <...>" and
goes into a break loop.  The message is triggered when the program notices
that its arrays have been set to strange lists of NIL's.

On some implementations, depending on when the GC is triggered, the program
may instead get a PDL overflow because one of its functions is attempting to
recurse down a bogus 150 element list (a the garbage array element)
before it discovers that the arrays have been munged.  If this happens,
simply change the size of list space by +/- 1000 or so and try again.  The
garbage collection will then occur at a different time, and the program's
array-testing code will probably win.

The arrays in question are called SIZE, PEG, TOP, and NEXT-TO-TOP.
Their indices run from 0 to 4.  These arrays are supposed to contain
numbers or lists, but after the garbage collector runs, some elements
contain long lists of NIL, from 20 to 150 elements.  Moreover, these
bogus lists seem to share structure, e.g.  the 20 element list is a tail
of the 150 element list.

We get essentially the same results running on CMU-10A, CMU-20C, and
MIT-MC.  The program also lost the same way in compiled form (on
CMUA.)

-- Dave Touretzky  (on the BUG-LISP mailing list)
   Glenn Iba	   (Iba @ CMUA)