Re: Stack calibration

[Neil Jerram]

2008/9/30 Neil Jerram <address@hidden>:
>
> Well, ideally we should have a solution that works automatically in
> all circumstances...

FWIW, I'm actually thinking now that this stack calibration stuff is
becoming way too tricky, in at least two ways.

1) The concept of the 'stack debug option being expressed in terms of
some other "canonical" combination of OS, compiler and compiler
optimization level.  (I struggle to describe this clearly, here, and
in comments in the code, and I'm sure I would struggle in the manual
too - so that's a bad sign!)

2) The complexity that my latest patch adds to the Guile build
process.  And even with this complexity we still don't cover all the
cases (notably cross compiling).

Reviewing the history, we find that this work was prompted by people
reporting Stack overflow errors when building Guile or when running
make check [1].  We also find that such errors were _still_ reported
by people who had some version of the calibration patch in place [2].
And there was a case, not yet understood, where the error was
apparently caused by configuring without threads [3].

There was also a general discussion of how stack checking is
implemented [4], which I think is sufficient to say that we should
keep it basically in its current form (rather than implement an eval
frame counter, say).

[1] http://www.mail-archive.com/address@hidden/msg04401.html
[2] http://article.gmane.org/gmane.lisp.guile.bugs/3881
[3] http://thread.gmane.org/gmane.lisp.guile.user/6628/focus=6629
[4] http://www.nabble.com/Re:-stack-overflow-td15467458.html

Taking everything together, my thinking now is...

- The problem we actually need to solve is getting a stack overflow
while running make and/or make check, and there may be other ways of
doing that than trying to pick the right number, and to interpret that
number such that it has the same effect on all platforms.

(For example, I think it would be fine if stack checking was disabled
during make and make check, and (post build/install) when loading
boot-9.scm.  We don't need to guard against C stack overflow when
running our own test suite, or when loading boot-9.scm, because
overflow in those contexts isn't going to hurt anyone.  The point of
stack checking is to protect against runaway user/developer code (or
Guile code being called from user/developer code).)

- Based on [2], it sounds like there is part of this issue that we
don't yet understand - i.e. not just the stack growing bigger than the
default 20000 words.

I plan to try and investigate [2] and [3] more, then hopefully propose
something (simpler than my latest patch!).

Regards,
        Neil