Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[BUG] Installing a package from GitHub appears to send NPM into an indefinite, high CPU usage frenzy #3787

Closed
1 task done
brianjenkins94 opened this issue Sep 23, 2021 · 3 comments
Closed
1 task done

[BUG] Installing a package from GitHub appears to send NPM into an indefinite, high CPU usage frenzy #3787

brianjenkins94 opened this issue Sep 23, 2021 · 3 comments
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release

Comments

@brianjenkins94
Copy link

brianjenkins94 commented Sep 23, 2021 •
edited
Loading

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

High CPU usage with no sign of stopping.

Expected Behavior

The package gets installed.

Steps To Reproduce

npm install brettz9/rollup-plugin-postprocess#update --save-dev

Environment

  • OS: macOS 10.15.7 (19H524)
  • Node: v16.9.1
  • npm: 7.23.0
@brianjenkins94 brianjenkins94 added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Sep 23, 2021
@lukekarrys lukekarrys removed the Needs Triage needs review for next steps label Sep 23, 2021
@lukekarrys
Copy link
Contributor

Thanks for the issue! I've confirmed this happens on the latest npm v7.24.0 and I was able to get an error log by SIGINT-ing the process at the first sign it was hitting an infinite loop: 2021-09-23T17_46_08_912Z-debug.log.

This seems to point to an issue within arborist as it loops on placeDep when preparing the git dep. This might be a duplicate of #3385 but I'm keeping this open since this one install of a git dep always fails for me.

@lukekarrys lukekarrys mentioned this issue Sep 23, 2021
Closed
1 task
@lukekarrys lukekarrys added the Priority 1 high priority issue label Sep 23, 2021
@isaacs isaacs mentioned this issue Sep 24, 2021
Closed
@isaacs
Copy link
Contributor

isaacs commented Sep 24, 2021

Simple reproduction case:

project -> (a)
a -> (x, y, j@1)
x -> PEER(j@1)
y -> PEER(j@2)

Or:

npm i @isaacs/peer-dep-conflict-infinite-loop-a

More details in npm/arborist#325

@isaacs
Copy link
Contributor

isaacs commented Sep 24, 2021

The fact that it hits this loop while preparing a git dep is a red herring. The root cause is just an install that has this particular shape of dependency graph.

@isaacs isaacs mentioned this issue Sep 25, 2021
Closed
1 task
@lukekarrys lukekarrys mentioned this issue Sep 25, 2021
Closed
1 task
isaacs added a commit to npm/arborist that referenced this issue Sep 27, 2021
@isaacs
fix: avoid infinite loops in peer dep replacements
6c55983 
Fix: #325
Fix: npm/cli#3787

Replacing a peerDep and leaving it to buildIdealTree to do the right
thing can lead to infinite regress in some cases.

For example:

```
project -> (a)
a -> (x, y, j@1)
x -> PEER(j@1)
y -> PEER(j@2)
```

In this case, when we get to the `j` peer dependency, we find that
there's nowhere to place it (since it's relied upon by a dependency at
the top level, either x or y), so we replace the conflicted version, and
expect that buildIdealTree will find a new home for it.

However, the next pass does the same thing, and so on.

This patch addresses the problem in the following way.

1. Collect all the peerEntrySets containing the dependency to be replaced.
2. If all of them _can_ be placed deeper in the tree, we remove the
   conflicting peerEntrySet, and mark all incoming edges as needing
   re-evaluation.  In the case described above, this means that `x` will be
   removed as well as `j`, and eventually placed under `a`, where there is
   no conflict.
3. If any peerEntrySet _cannot_ be placed deeper in the tree, then we mark
   the offending edge as overridden, so that it won't be re-evaluated by
   buildIdealTree.

This properly finds the nested tree fully when it is possible, and prints
the appropriate ERESOLVE warning when it is not.
@lukekarrys lukekarrys mentioned this issue Sep 30, 2021
Closed
1 task
@rexxars rexxars mentioned this issue Aug 18, 2022
Open
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@isaacs @lukekarrys @brianjenkins94