Composer: Cannot update packages anymore "Fatal error: Out of memory (allocated 1392771072) (tried to allocate 268435456 bytes)"

[picks44]

My composer.json:

{
    "name": "gregv/des-iwid",
    "description" : "The Desoutter Industrial Tools multilingual website",
    "license": "proprietary",
    "type": "project",
    "autoload": {
        "psr-4": {
            "": "src/"
        },
        "classmap": [
            "app/AppKernel.php",
            "app/AppCache.php",
            "vendor/phpdocx/Classes/Phpdocx"
        ]
    },
    "require": {
        "cloudconvert/cloudconvert-php": "^2.2",
        "cspoo/swiftmailer-mailgun-bundle": "^0.3.1",
        "doctrine/doctrine-bundle": "~1.4",
        "doctrine/orm": "^2.4.8",
        "egeloen/ckeditor-bundle": "^4.0",
        "fresh/vich-uploader-serialization-bundle": "^1.0",
        "friendsofsymfony/jsrouting-bundle": "^1.6",
        "friendsofsymfony/user-bundle": "~2.0",
        "helios-ag/fm-elfinder-bundle": "^6.2",
        "hshn/base64-encoded-file": "^1.2",
        "incenteev/composer-parameter-handler": "~2.0",
        "jms/di-extra-bundle": "^1.8",
        "jms/i18n-routing-bundle": "^2.0",
        "jms/serializer-bundle": "^2.0",
        "jms/translation-bundle": "^1.3",
        "knplabs/knp-menu-bundle": "^2.0",
        "knpuniversity/oauth2-client-bundle": "^1.16",
        "league/oauth2-linkedin": "^2.1",
        "leaseweb/memcache-bundle": "^2.1",
        "lexik/jwt-authentication-bundle": "^2.4",
        "liip/imagine-bundle": "^1.6",
        "mediafigaro/google-analytics-api-symfony": "^1.0",
        "ninsuo/symfony-collection": "^2.1",
        "php": ">=5.3.9",
        "php-http/guzzle6-adapter": "^1.1",
        "sensio/distribution-bundle": "~5.0",
        "sensio/framework-extra-bundle": "^3.0.2",
        "stof/doctrine-extensions-bundle": "^1.2",
        "symfony/assetic-bundle": "^2.8",
        "symfony/monolog-bundle": "~2.4",
        "symfony/swiftmailer-bundle": "~2.3",
        "symfony/symfony": "2.8.*",
        "twig/extensions": "^1.4",
        "vich/uploader-bundle": "^1.3",
        "willdurand/js-translation-bundle": "^2.6"
    },
    "require-dev": {
        "sensio/generator-bundle": "~3.0",
        "symfony/phpunit-bridge": "~2.7",
        "doctrine/doctrine-fixtures-bundle": "^2.3"
    },
    "scripts": {
        "symfony-scripts": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
        ],
        "post-install-cmd": [
            "@symfony-scripts",
            "Fuz\\Symfony\\Collection\\ScriptHandler::postInstall"
        ],
        "post-update-cmd": [
            "@symfony-scripts",
            "Fuz\\Symfony\\Collection\\ScriptHandler::postUpdate"
        ]
    },
    "config": {
        "bin-dir": "bin",
        "component-dir": "web/assets"
    },
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "symfony-assets-install": "hard",
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        }
    }
}

Output of composer diagnose:

Checking composer.json: WARNING
Defining autoload.psr-4 with an empty namespace prefix is a bad idea for performance
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.6.5
PHP version: 5.6.18
PHP binary path: C:\wamp\bin\php\php5.6.18\php.exe

When I run this command:

php -d memory_limit=-1 composer.phar update -vvv

I get the following output:

Fatal error: Out of memory (allocated 1392771072) (tried to allocate 268435456 bytes) in phar://C:/wamp/www/DES
iwid/composer.phar/src/Composer/DependencyResolver/Solver.php on line 220

[alcohol]

How much memory does your machine have?

Also, can you run the update command with --profile to see where the biggest jumps in memory are made?

[picks44]

I have 16Gb of RAM.

Here is the ouput of the profiler

php composer.phar update --profile
[8.7MB/0.00s] Loading composer repositories with package information
[9.1MB/1.28s] Updating dependencies (including require-dev)

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 134217728 bytes) in phar://C:/wamp/www/DESiwid/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

[picks44]

And with verbose, the last lines are

...
[192.7MB/16.11s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-willdurand$js-translation-bundle.json from cache
[193.2MB/16.63s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$swiftmailer-bridge.json from cache
[194.5MB/16.73s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-egulias$email-validator.json from cache
[205.2MB/17.54s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-phpdocumentor$reflection.json from cache
[205.3MB/17.55s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$browser-kit.json from cache
[207.1MB/17.67s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$css-selector.json from cache
[208.7MB/17.76s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$debug-bundle.json from cache
[210.0MB/17.84s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$dom-crawler.json from cache
[211.6MB/17.92s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$expression-language.json from cache
[212.7MB/18.02s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$ldap.json from cache
[213.4MB/18.07s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$property-info.json from cache
[214.4MB/18.13s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$proxy-manager-bridge.json from cache
[215.9MB/18.22s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$security-guard.json from cache
[216.6MB/18.28s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$security-http.json from cache
[218.3MB/18.41s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$var-dumper.json from cache
[219.4MB/18.49s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$web-profiler-bundle.json from cache
[222.2MB/20.22s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-phpunit$phpunit.json from cache
[508.9MB/41.65s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-phpdocumentor$reflection-docblock.json from cache
[509.5MB/41.68s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-phpdocumentor$type-resolver.json from cache
[515.3MB/41.90s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$workflow.json from cache
[749.0MB/50.38s] Reading C:/Users/gregv/AppData/Local/Composer/repo/https---packagist.org/provider-doctrine$phpcr-odm.json from cache

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 134217728 bytes) in phar://C:/wamp/www/DESiwid/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

[alcohol]

It looks like it tries to allocate roughly 1gb, but memory limits won't allow more. It seems to me that the -d memory_limit=-1 flag is not passed on properly to the php process that runs composer. But I have no experience developing on Windows, so I cannot debug this for you. You will have to investigate further yourself.

[curry684]

It could be generic - the mechanism to fork to disable Xdebug could be erroneously not forwarding the -d memory_limit=-1 flag.

Nevertheless PHP-CLI should in general always be configured with memory_limit=-1.

[picks44]

I have the same issue when updating the php.ini to memory_limit=-1 or memory_limit=5G...
It just stopped working one morning...

[alcohol]

Did you check with php --ini if you have modified the correct ini files?

Are you certain that the composer.phar does not actually use a different php binary to run composer? Can you check the contents of your composer.phar and see if it as perhaps a shim (e.g. a dummy file that calls another binary with some modifiers/flags/etc)?

[picks44]

Yes, I've checked this. I can delete my composer.phar file and download a fresh copy to see if there is any difference...

[picks44]

Doesn't change anything :/

[joshstoik1]

I experienced the same issue this morning. Yesterday everything was fine, but today any attempt to run composer update --no-dev or composer install --no-dev on an existing project was met with an endless loop during the autoloader generation process.

I think the problem might be with the source file at https://getcomposer.org/composer.phar. I am not experiencing any issues when using the 1.6.5 Phar release from Github.

[xlr-8]

Same issue here, with composer install, things worked fine on monday but started crashing yesterday.

Command with [composer 1.7-dev (089f3803de4797a78e6e1feddfbbb74920c5ad2c) 2018-05-15 14:07:13]: export SYMFONY_ENV=prod && php -dmemory_limit=-1 /home/www/website/composer.phar install --prefer-dist --no-progress --no-interaction --optimize-autoloader --no-dev

Results in:

mmap() failed: [12] Cannot allocate memory
PHP Fatal error:  Out of memory (allocated 3827302400) (tried to allocate 262144 bytes) in phar:///home/www/website/composer.phar/src/Composer/Autoload/AutoloadGenerator.php on line 926

The memory flag wasn't required before, and the server's memory was increased from 1Go to 3.5, without much success. I tried with both version of PHP 7.1.8-1ubuntu1 & 7.1.17-0ubuntu0.17.10.1 which resulted in the same.

The only way to make the previous command work with the recente version of composer, is _surprisingly_ to remove the --no-dev flag.

I tried with the version 1.6.5 Composer version 1.6.5 2018-05-04 11:44:59 and everything worked as previously.

[curry684]

Pinging @Seldaek in if it's just occurring in dev branch.

[Seldaek]

I think #7316 sounds like the culprit for the issue happening at autoload time with --no-dev. Might not handle circular dependencies well or something. That sounds unrelated to the memory issue initially reported in this issue though.

[curry684]

Looking at that code: yes, circular dependency will most certainly make it run out of memory pretty quickly, it doesn't handle them whatsoever.

[imsheng]

I have the same problem.

[picks44]

OK I found a solution : I was using WAMP 32bits, and switched to WAMP 64bits, that solved everything.
Closing.

[dol]

We've been hit by this issue as well. But only if we use the latest composer dev version.
Composer version: 1016cf19b2c6212b76df5b4f58ba1be8382e5945

php -d memory_limit=-1 composer.phar dump-autoload --no-dev

This uses all the the remaining memory and starts to swap. I can confirm that 22025f2e29dbcae962efaec49e3c8677edde8a6f works ok. But since the merge of #7316 ( b0be87177d62611e0bf22825942be4820e7295c4 ) it starts with the memory eating. :cookie:

[Seldaek]

@dol @joshstoik1 @xlr-8 @imsheng can you please try again with the latest snapshot? Hopefully https://github.com/composer/composer/commit/eedbd218f52c526ec41c6c623137c3781eb4d928 fixes it.

[dol]

I can confirm that eedbd218f52c526ec41c6c623137c3781eb4d928 fixes the issue.

[ealanisg]

Did this on my linux box and it worked

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

[curry684]

That implies your development machine did not have any swap space to begin with, and it was simply running out of memory the hard way.

[kareemashraf]

i had the same problem and only @ealanisg 's solution fixed it

[curry684]

As my comment above indicates: that's not so strange as it implies you were running a developer machine without a swapfile. That's suicide unless it has at least 16GB of RAM anyway.

[webdoc79]

i had the same problem and only @ealanisg 's solution fixed it Thanks!!!!

[bokino17]

i had the same problem and only @ealanisg 's solution fixed it Tks very !!!!

[sotisoti]

Yep, @ealanisg's fix works for me (I have a 1GB vps). Thanks.

[rapliandras]

Swapfile works but you should optimize composer.json to use more explicit dependencies if possible. Sometimes pulling and comparing too many versions are responsible for increased memory consumption.

[cybersholt]

In case anyone else comes across this and is stuck with a 32 bit version of php on Windows, this patcher worked for me https://ntcore.com/?page_id=371, I applied it to the php.exe and composer updated it no problems at all, memory usage was just a touch over 2GB.

[curry684]

and is stuck with a 32 bit version of php on Windows

Given that all maintained Windows versions out there only have 64-bit versions and switching to a 64-bit build of PHP takes less than 5 minutes - how could you get stuck on a 32-bit version of PHP?

[cadmax]

@ealanisg tks brother!

[kleidi90]

I solved this issue with a simple composer self-update. My memory_limit is set to 2G

[devkbsc]

My project has been hold down cause of this issue :

https://github.com/composer/composer/issues/8063#issuecomment-478987263

I have created an issue for the same error! But the issues closed and referenced to this page!

[devkbsc]

Today is April 2 , Not april 1 @kleidi90

C:\xampp\htdocs\risym>composer self-update
You are already using composer version 1.8.4 (stable channel).

C:\xampp\htdocs\risym>composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)

VirtualAlloc() failed: [0x00000008] Les ressources mÚmoire disponibles sont insuffisantes pour traiter cette commande.


VirtualFree() failed: [0x000001e7] Tentative dÆaccÞs Ó une adresse non valide.


VirtualAlloc() failed: [0x00000008] Les ressources mÚmoire disponibles sont insuffisantes pour traiter cette commande.


VirtualFree() failed: [0x000001e7] Tentative dÆaccÞs Ó une adresse non valide.

PHP Fatal error:  Out of memory (allocated 1553989632) (tried to allocate 4096 bytes) in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Fatal error: Out of memory (allocated 1553989632) (tried to allocate 4096 bytes) in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

C:\xampp\htdocs\risym>php -r "echo ini_get('memory_limit').PHP_EOL;"
10G

Here is what happend to me after self-update

[stof]

@devkbsc in your case, you don't reach the PHP memory limit. You reach the system memory limit.

[devkbsc]

My system has enough memory space

@stof

[curry684]

@devkbsc with all due respect, you should be reading up on basic computer knowledge if you're showing disk space numbers to prove you're not out of system memory. The difference is explained for example here concisely, or more thoroughly here. You should really be aware of such things before using software development tooling.

[gopalkohli]

self-update worked for me

[shadman]

You may also get resolved by just removing vendor directory and re-execute composer install command.

[devkbsc]

@curry684 I have found where the problem existed! ComposerSetup done! There are a file created by composer need to be placed in the project folder! it's composer.phar need to be synched each time i use composer command in CMD-windows! I got to understand this scenarie took months! Thanks for your fantastic guidence!

[devkbsc]

@curry684 the comprehension sometimes depends on the terms we use in common ! In my knowledge "SYSTEM" is very common term uses for computer host

[Michira]

Try Self-Update

[tusharmp]

@ealanisg Thanks

[mzubairharoon]

Thank you @ealanisg. Your solution works, does that mean our ubuntu didn't have a swap partition (ec2 server)?

[vinika02]

Hi, this solution will fix your problem.

Update your php.ini file then restart Apache or your server
example:
memory_limit=128M
to
memory_limit=1128M

It's work on me.

[top-master]

Hi, closing my web-browser and any other memory expensive application fixed this for me.
(It required 1.3 GB free RAM which I had to free)

[laocoi]

In my case, the solution is update composer
composer self-update

[connecteev]

i had the same problem and only @ealanisg 's solution fixed it Thanks!!!!

[benjbmc]

Did this on my linux box and it worked

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

Thank you @ealanisg it worked for me too,
just to know more about these commands you can go check this page on composer website.

Actually it was given by the error in terminal :
The following exception is caused by a lack of memory or swap, or not having swap configured Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details