[Bug-openmcl] recursion consumes stack resources. The reader is recursive.

[Gary Byers]

One of the tests in Paul Dietz's (generally very good) ANSI CL test suite
does something like:

(read-from-string "#8191((((( ...)))))"

where the string contains 8191 leading open parens and 8191 trailing
close parens.  The #( reader macro shares quite a bit of code with the
#\( reader macro in OpenMCL, and each recursive call stack-allocates a
few dozen bytes worth of local variables (that might otherwise have to
be heap-allocated.)

The bug is that a "soft overflow" (a situation that should signal a
SERIOUS-CONDITION) on the stack where DYNAMIC-EXTENT things are
allocated is treated as a "hard overflow" (a situation where the only
safe option is to reset the thread as gracefully as possible and
announce that "stacks [have been] reset due to overflow").

(A related bug that the test doesn't provoke: there needs to be more
hysteresis in stack-overflow recovery.  If two of a thread's stacks
overflow at nearly the same time, it's possible to get into a
situation where the act of recovering from the overflow on stack
A causes an overflow on stack B.)

The test doesn't appear to be designed to test implementation limits
on reading deeply nested list expressions, but may recognize that they
exist: it tries to limit this to (1- (min 10000
array-dimension-limit)), which is where the 8191 comes from.

Stack-overflowing when trying to read deeply-nested expressions isn't
a bug per se, but it should probably be fixed.  A couple of years ago,
OpenMCL had (and MCL still has) "segmented" stacks, composed of
discontiguous segments that were glued together (mostly) transparently.
Unfortunately, it wasn't entirely transparent: there were obscure bugs
that were hard to reproduce associated with that code, and the scheme
limited the size of objects that could be successfully stack-allocated.