Skip to content

cabal uses too much memory when solving for setup dependencies #2899

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
grayjay opened this issue Oct 28, 2015 · 3 comments
Closed

cabal uses too much memory when solving for setup dependencies #2899

grayjay opened this issue Oct 28, 2015 · 3 comments

Comments

@grayjay
Copy link
Collaborator

grayjay commented Oct 28, 2015

Some combinations of setup and library dependencies cause the solver to use more and more memory. I ran cabal install --dry-run --max-backjumps -1 with this cabal file for five minutes with about 16GB of memory. I used GHC 7.10.2.

name:                example
version:             0.1.0.0
cabal-version:       >=1.8
build-type:          Custom

custom-setup
  setup-depends:       aeson, hackage-server, yi

library
  build-depends:       aeson, mtl, leksah

cabal-memory-usage

My best guess is that it is related to the addLinking function creating linked nodes from existing unlinked nodes. When a node is referenced by a later sibling, it probably isn't garbage collected immediately after it is traversed.

return $ PChoice qpn gr (cs' `P.union` P.fromList newCs)

@23Skidoo
Copy link
Member

/cc @edsko, @kosmikus

grayjay added a commit to grayjay/cabal that referenced this issue Jul 10, 2016
The solver creates linked nodes by copying existing unlinked nodes. Previously,
the subtrees shared data, which caused a space leak. This commit gives the
subtrees dummy arguments to prevent sharing.
@grayjay
Copy link
Collaborator Author

grayjay commented Jul 10, 2016

I encountered this issue again while testing with a long-running command: cabal install leksah yesod hackage-server

This uses GHC 8.0.1.
issue-2899

The -v3 log shows that the solver chose to link a setup dependency near the top of the tree (level 8). It didn't return to that level until around the time that the memory usage dropped. When it descended again, it used a different goal order and chose the setup dependencies much farther down in the tree. I think that the spike in memory usage can be explained by the solver retaining the whole subtree starting where it chose the first setup dependency.

grayjay added a commit to grayjay/cabal that referenced this issue Jul 17, 2016
It uses a lot of memory but doesn't fail.
grayjay added a commit to grayjay/cabal that referenced this issue Nov 13, 2016
The solver creates linked nodes by copying existing unlinked nodes. Previously,
the subtrees shared data, which caused a space leak. This commit combines the
"build" and "addLinking" tree traversals so that the nodes are copied before
they are expanded into full trees.
grayjay added a commit to grayjay/cabal that referenced this issue Nov 19, 2016
The solver creates linked nodes by copying existing unlinked nodes. Previously,
the subtrees shared data, which caused a space leak. This commit combines the
"build" and "addLinking" tree traversals so that the nodes are copied before
they are expanded into full trees.
grayjay added a commit to grayjay/cabal that referenced this issue Nov 19, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Nov 19, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Nov 20, 2016
The solver creates linked nodes by copying existing unlinked nodes. Previously,
the subtrees shared data, which caused a space leak. This commit combines the
"build" and "addLinking" tree traversals so that the nodes are copied before
they are expanded into full trees.
grayjay added a commit to grayjay/cabal that referenced this issue Nov 20, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Nov 22, 2016
The solver creates linked nodes by copying existing unlinked nodes. Previously,
the subtrees shared data, which caused a space leak. This commit combines the
"build" and "addLinking" tree traversals so that the nodes are copied before
they are expanded into full trees.
grayjay added a commit to grayjay/cabal that referenced this issue Nov 22, 2016
@grayjay grayjay self-assigned this Nov 27, 2016
23Skidoo added a commit that referenced this issue Dec 1, 2016
Solver: Fix space leak in 'addlinking' (issue #2899).
@grayjay
Copy link
Collaborator Author

grayjay commented Dec 1, 2016

Fixed in #4110.

@grayjay grayjay closed this as completed Dec 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants