On latest win32 build (1.0.0.26) I also get the stack exhaustion
* (sb-pcl:ensure-class-using-class (find-class 'standard-class) 'alma
:direct-slots '((:name name)))
debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED:
Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitel
y recursive function calls, or a tail call that SBCL cannot or has not
optimized away.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.

"Attila Lendvai" <attila.lendvai@...> writes:
> this expression kills sbcl cvs with a memory fault:
>
> (sb-pcl::ensure-class-using-class (find-class 'standard-class) 'alma
> :direct-slots '((:name name)))
On my system, an x86/Linux machine, the stack exhaustion protection
works acceptably, in that the whole lisp doesn't die; what platform
are you on, and do "normal" cases of stack exhaustion get caught? The
only difference that my change in sbcl-1.0.0.11 made was relying on
the stack exhaustion protection rather than a recursion detector in
accessor methods.
Anyway, the fact that the stack exhaustion detector works for me is
small consolation, because after that almost nothing of CLOS works, as
it has a somewhat confused notion of what a standard class is. It is
entirely possible that a small list of "built-in" classes should be
protected from this kind of accidental redefinition; I'd suggest using
a mechanism similar to package locks, maybe protecting classes with
names in CL and SB-MOP from redefinition?
Cheers,
Christophe