Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,393
    • Issues 4,393
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 376
    • Merge Requests 376
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #1466

Closed
Open
Opened Jun 28, 2007 by Simon Marlow@simonmarDeveloper

Stack check for AP_STACK

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.

Trac metadata
Trac field Value
Version 6.6.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system Unknown
Architecture Unknown
Assignee
Assign to
8.0.1
Milestone
8.0.1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#1466