[Openmcl-devel] Stack overflow on value stack when compiling (Clozure CL on Windows)

[Mark H. David]

Thanks, I found out it was actually my bug, a recursive macro.  This was useful and helpful for finding it, however, and it probably will be useful in the future. 
Thanks!
-Mark

----- Original message -----
From: Gary Byers <gb at clozure.com>
To: "Mark H. David" <mhd at yv.org>
Cc: openmcl-devel at clozure.com
Subject: Re: [Openmcl-devel] Stack overflow on value stack when compiling (Clozure CL on Windows)
Date: Tue, 28 May 2013 16:23:46 -0600 (MDT)

You can try to determine why the overflow occurred (e.g., whether it's
due to infinite recursion or merely due to deep recursion that
exhausts a finite stack.)  Looking at a backtrace would be the first
step; looking at a backtrace when the stack has oveflowed can create
its own set of problems.  In the command-line REPL, the :nframes
break-loop command and options to the :b command can be used to view a
more manageable region of the backtrace.  I don't know about what
support other environments (e.g., SLIME) may provide.

If you're convinced that the recursion would terminate if the stack
was larger, you need to ensure that the thread that your code is 
running on has a larger stack (at least a larger "value" stack in this
case); how you do that depends on what thread that code is running on
and on how that thread was created.  If you created the thread yourself
(via PROCESS-RUN-FUNCTION or equivalent) the manual describes arguments
that control the thread's stack sizes.

<http://ccl.clozure.com/manual/chapter7.7.html#f_process-run-function>

If the thread is the initial listener thread created by the command-line
CCL, then the -Z or --thread-stack-size argument can be used to set the
listener tread's stack sizes based on the argument's value.

The little bit that I know about SLIME includes the fact that it sometimes
creates threads for reasons that are far from clear to me.

By default,  the "value" stack of a CCL thread is ~1MB in size on 32-bit
versions of CCL and ~2MB on 64-bit versions.  The size of a stack (in bytes)
is related to the depth of recursion, but the relationship depends on how
the function(s) in question use the stack.

It's certainly possible for things that happen at compile-time (the compiler
itself, the reader ...) to do things that're deeply but finitely recursive,
but it isn't easy for these things to overflow; that likely would involve
10s of thousands or more recursive function calls.  (Possible, yes; likely,
probably not.)

On Tue, 28 May 2013, Mark H. David wrote:

> I'm compiling some huge functions in Clozure Lisp on Windows.  If I run into "Stack overflow on value stack." as a compiler error while compiling, is there anything I can do, e.g., a command line arg, or is there something to change in the Lisp environment?  I'm aware I can change my code, but is there any way short of that?
> Thanks,
> Mark
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>