#1466: Stack check for AP_STACK
-------------------------------+--------------------------------------------
Reporter: simonmar | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: Runtime System | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Moderate (1 day) | Os: Unknown
Testcase: concprog001 | Architecture: Unknown
-------------------------------+--------------------------------------------
This is a bug I uncovered in the interpreter, that I think is also present
in the compiler.
When compiling code for a function or thunk, we aggregate the stack usage
from case continuations up to the top of the function/thunk and perform a
single stack check. This normally works fine: we know the maximum amount
of stack that will be required in the evaluation of this function/thunk,
and we check for it up front.
However, this goes wrong if the evaluation is suspended by an asynchronous
exception: the stack is broken into chunks and stored in `AP_STACK`
objects, which may later be resumed. On resumption, we might not have
enough stack any more: the code might now be running on another stack
entirely, even.
Our proposed solution is as follows:
* Continuations that require more than a certain amount of stack (say 4k)
do their own stack checks.
* an AP_STACK object records the amount of stack available at the time it
was suspended, if the amount is <4k. On resumption of an AP_STACK, we
ensure that at least this amount of stack is available. (there's a
spare half-word field in AP_STACK that we can use for this).
The 4k limit is important: it puts a bound on the amount of stack growth
due to evaluating an AP_STACK. Essentially the 4k limit is large enough
that it almost never happens.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1466>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
