Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 5.5k
    • Issues 5.5k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 629
    • Merge requests 629
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #22927
Closed
Open
Issue created Feb 07, 2023 by Ben Gamari@bgamari🐢Maintainer

Nonmoving GC may drop update remembered set blocks due to `setNumCapabilities`

Storage.c:storageAddCapabilities currently has the following:

    // Initialize NonmovingAllocators and UpdRemSets
    if (RtsFlags.GcFlags.useNonmoving) {
        nonmovingAddCapabilities(to);
        for (i = 0; i < to; ++i) {
            nonmovingInitUpdRemSet(&getCapability(i)->upd_rem_set);
        }
    }

This is subtly wrong: the lower iteration bound of 0 means we end up re-initializing (and therefore clearing) the update-remembered sets of capabilities which already exist. This lower bound rather should be from.

This can result in undefined behavior in programs using the nonmoving GC and setNumCapabilities.

Edited Feb 07, 2023 by Ben Gamari
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking