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.

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

Hang on Resolving dependencies through SAT for over 22h #7240

Open
kenorb opened this Issue Apr 5, 2018 · 10 comments

Comments

Projects
None yet
8 participants
@kenorb
Copy link

kenorb commented Apr 5, 2018

My composer.json:

{
  "require": {
    "behat/behat":                     "^2@stable",
    "dealerdirect/phpcodesniffer-composer-installer": "^0.4.4",
    "drupal/coder":                    "^8@stable",
    "drush/drush":                     "^8@stable",
    "jakub-onderka/php-parallel-lint": "^1@stable",
    "pdepend/pdepend":                 "^2@stable",
    "pheromone/phpcs-security-audit":  "^1@stable",
    "phploc/phploc":                   "^4@stable",
    "phpmd/phpmd":                     "^2@stable",
    "phpunit/phpcov":                  "^4@stable",
    "phpunit/phpunit":                 "^6@stable",
    "phpunit/phpunit-selenium":        "^1@stable",
    "sebastian/phpcpd":                "^3@stable",
    "squizlabs/php_codesniffer":       "^2@stable"
  },
  "minimum-stability": "dev"
}

Output of composer diagnose:

OK
Checking composer version: OK
Composer version: 1.6.3
PHP version: 7.1.14
PHP binary path: /usr/local/Cellar/php71/7.1.14_25/bin/php

When I run this command:

time composer -vvv install 

I get the following output:

Loading config file ./composer.json
...
Resolving dependencies through SAT
...
load: 2.95  cmd: php 6462 running 35420.91u 158.86s
^C
real:1377m58.550s user:0m0.022s sys:0m0.016s

The command was run for over 22 hours and was stuck on 'Resolving dependencies through SAT' step. The PHP process used 99% of CPU and if I didn't cancel it, it could go forever I think.

Related: GH-7224 with the similar composer.json, but the above file it seems it is stuck in some loop forever. I've reproduced the issue on few different machines.

@kenorb

This comment has been minimized.

Copy link
Author

kenorb commented Apr 9, 2018

I've tried to narrow down the required versions, but it didn't help:

{
  "require": {
    "behat/behat":                     "^2.5@stable",
    "dealerdirect/phpcodesniffer-composer-installer": "^0.4",
    "drupal/coder":                    "^8.2@stable",
    "drush/drush":                     "^8.1@stable",
    "jakub-onderka/php-parallel-lint": "^1.0@stable",
    "pdepend/pdepend":                 "^2.5@stable",
    "pheromone/phpcs-security-audit":  "^1.0@stable",
    "phploc/phploc":                   "^4.0@stable",
    "phpmd/phpmd":                     "^2.6@stable",
    "phpunit/phpcov":                  "^4.0@stable",
    "phpunit/phpunit":                 "^6.5@stable",
    "sebastian/phpcpd":                "^3.0@stable",
    "squizlabs/php_codesniffer":       "^2.9@stable"
  },
  "minimum-stability": "dev"
}

The Composer was running for over 1h calculating the dependencies, so I had to stop it.

@kenorb

This comment has been minimized.

Copy link
Author

kenorb commented Apr 9, 2018

In one configuration which took like over half an hour to run, the dependency error was long for over 600 lines. One weird line was like:

 [exec]     - Removal request for vipsoft/code-coverage-extension == 2.5.9999999.9999999-dev

The latest version of this package is 2.5.0.5 (composer show -a vipsoft/code-coverage-extension), so does it mean the Composer had to traverse through 9999999*9999999 versions for some reason? If so, this would be a pretty bad and could explain the hang. However, after removing vipsoft/code-coverage-extension (as shown above) still takes hours to run.

Attaching the error logs: Composer_error1.txt.gz, Composer_error2.txt.gz, but these are generated only in certain scenarios, in most cases the dependencies takes few hours to compute.

@picasso250

This comment has been minimized.

Copy link

picasso250 commented Apr 10, 2018

Resolving dependencies through SAT
Dependency resolution completed in 305.450 seconds

Is there better ways to resolve dependency?

Even, I think we can introduce a faster resolving mode, that it only expand ~2.0 to 2.0.0.
That is, it only guess the most possible version or fail directly to ensure the speed.

@Seldaek Seldaek added the Support label Apr 12, 2018

@stof

This comment has been minimized.

Copy link
Contributor

stof commented Apr 25, 2018

2.5.9999999.9999999-dev is the normalized version of 2.5.x-dev, i.e. the 2.5.x branch of the repo

@codeistalk

This comment has been minimized.

Copy link

codeistalk commented Jun 5, 2018

Any updates

@staabm

This comment has been minimized.

Copy link
Contributor

staabm commented Jun 5, 2018

still reproducible with the latest composer version?

@cocochepeau

This comment has been minimized.

Copy link

cocochepeau commented Jun 11, 2018

Still experiencing it (upgrade from lumen "5.5.*" to "5.6.*").

@codeistalk

This comment has been minimized.

Copy link

codeistalk commented Jun 12, 2018

Yes, tried all possible from stackoverflow and here, but it just get stuck.

@arku31

This comment has been minimized.

Copy link

arku31 commented Mar 13, 2019

I also experienced this. I have fixed my issues by updating some dependency versions. This is definitely a bug, this kind of conditions should lead to the error message and not hanging out but anyway it's kind of easy to "fix".

@kenorb

This comment has been minimized.

Copy link
Author

kenorb commented Mar 13, 2019

The workaround is to avoid using wildcards or too vague versions (this is based on my experience), so:

  • instead of 5.6.*, use ^5.6.1 (the latest known version, check at packagist.org),
  • instead of ^2 use ^2.0.0,
  • keep composer.lock present (or copy from existing machine which did already dependency processing), this helps Composer to process dependencies faster.

This avoids Composer guessing release numbers from 0 to 9999999, and traversing all permutations to match the final dependencies (as far as I understand it), most often causing Composer to fail due to out of memory after hours of processing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.