Re: stack overflow

[Mikael Djurfeldt]

2008/2/14, Ludovic Courtès <address@hidden>:
>  > Speaking as a user, I would prefer a solution where the evaluator
>  > measures stack size the same way as currently (i.e. without the need
>  > to do extra work at every return).  It is possible to estimate the
>  > average sizes of evaluator stack frames during startup and use this as
>  > a conversion factor in the debug-options interface (scm_debug_opts) so
>  > that the user setting is approximately consistent between platforms.
>
>
> Hmm, I don't see how we could reliably estimate this, and I'm afraid it
>  would add non-determinism (e.g., estimate that varies with the phase of
>  moon, dubious estimates, loads of users suddenly reporting stack
>  overflows because Fedora Core now ships with a bleeding-edge compiler
>  noone else uses, etc.).

I was thinking about inserting code which actually *measures* the size
of frames during startup.  This could be done, for example, by
introducing a primitive which uses the internal stack measuring
functions.  One could use this primitive to measure how much stack
space some code sample uses.  By our knowledge of how many evaluator
stack frames this code sample uses, we can compute a reliable estimate
for the running instance of Guile.