0.9.9.34:

0.9.9.34:
	Merge fix from Peter Van Eynde (sbcl-devel 2006-02-11 "cosmetic
	room bug") for a cosmetic room bug.
	... also fix a distinctly non-cosmetic scrub-control-stack bug
		resulting from the same issue.  This scrubbing failure
		appeared to cause heap corruption in powerpc/gencgc
		test builds; I think I understand why.

	The Cheney GC zeros the unused parts of the lisp control stack
	after it has completed the garbage collection.  This ensures
	that, if the active stack had no garbage pointers at the start
	of the collection, there is no region in the entire control
	stack (used or unused) which contains a garbage pointer, since
	every entry has either been scavenged or zeroed.  But since by
	assumption we start off with no garbage pointers, by
	mathematical induction we never scavenge one, so everything is
	safe.

	GENCGC doesn't perform this zeroing.  (Why?)  However,
	SCRUB-CONTROL-STACK does, before a GC.  This is slightly more
	dangerous, because we could in fact have incomplete stack frames
        lying below the stack pointer with an entry from a previous
        iteration of the heap, but I think it's OK by the same
        reasoning as before.  Failure to zero the stack, however, does
        leave the possibility of bogus pointers open when stack frames
        are extended but not every stack slot has yet been written to.
        This wasn't so much of an issue when the stack is
        scanned conservatively and ambiguous roots caused pinning, but
        under a precise stack scanning regime disaster ensues.