I got this error when running composer.phar update
on my VM:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 144115188075867549 bytes) in phar:///bin/composer.phar/src/Composer/Util/RemoteFilesystem.php on line 179
The composer.json
, if needed:
{
"description" : "The CodeIgniter framework",
"name" : "codeigniter/framework",
"license": "MIT",
"require": {
"php": ">=5.2.4",
"videlalvaro/php-amqplib": "2.5.*"
},
"require-dev": {
"mikey179/vfsStream": "1.1.*",
"videlalvaro/php-amqplib": "2.5.*"
}
}
The VM just recently recovered from a bad disk sector problem, and the guy running the VM said that the VM has been moved to a new disk. There are only Java, PHP, httpd, postgre, rabbitmq and the website itself in my VM, and it already ran perfectly for about 4 months before this happened. I'm using PHP 5.6.11. Can anyone help please?
memory_limit
exists because 144115188075867549 is exactly 128 petabytes if I did the calculation right...
vendor
directory and running the command again?
Check the Composer's troubleshooting wiki, especially the memory limit errors section.
For instance, by running the composer like this:
php -d memory_limit=-1 `which composer` update
I get no error anymore. So it is probably an insufficient memory issue that can be solved inline, without altering your default PHP configuration.
What the command above does is that it sets the PHP CLI memory limit to "unlimited" (ie. -1) and then it runs the inline composer update
command.
Please note that instead of `which composer` you should probably use the real path of your composer.phar
PHP script. The which composer
written inline (like in my example above) will be inline solved to your composer.phar
full path (you may use whatever form you like).
Note: in case both the physical and virtual memory is exceeded the above solution might fail as well. If that is the case then the obvious solution would be to increase your system's virtual memory then try again.
The only thing that solve my problem was doing this:
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1
From my experience, memory errors from composer usually means it is spending too much memory looking for the right combinations of packages to install, especially the version constraints are not specific enough. For example, ^5.2.4 matches 5.3 to 5.3.29, 5.4 to 5.4.45, etc. For each specific version and permutation, composer has to get the package's dependencies to check if all the constraints are met. This is usually when the memory consumption gets huge.
Once the versions have been figured out, the installation phase uses much less memory. The resolved versions for each package are also stored in a composer.lock file so that the specific permutation installed can be replicated in other environments. And this is the potential solution to your issue: run composer update in your dev machine (which should have enough memory), deploy the updated composer.lock, and run composer install on the server.
Composer install will always reference the existing composer.lock for the versions to install for each package, and thus should seldom run into memory issues.
For a reference on how to express version constraints in composer.json, check out https://getcomposer.org/doc/articles/versions.md
"aws/aws-sdk-php": "~3.2"
which was resolving to 3.204.0
. So I updated this constraint to "aws/aws-sdk-php": "~3.204"
and memory issue was gone. So I also reviewed constraints for other packages to avoid such a problem in future. I recommend to try this before playing around with memory_limit
, because it can really bite you on cloud-based setups.
Rather than permanently setting your memory limit to an increased number (or unlimited), I use this;
# Running an update
COMPOSER_MEMORY_LIMIT=-1 composer update
COMPOSER_MEMORY_LIMIT=-1 composer require PACKAGE/NAME
That temporarily set's the composer memory limit env variable to unlimited.
Solved by deleting the whole vendor folder, and then doing the composer update again, and it works... somehow. I don't even understand :v
composer.lock
file.
composer install
worked on Windows for me. I guess update comparisons take far more memory than a fresh install.
Katiak's answer worked but I had to modify it. You will need 4 GB of free space for this to work on a Linux machine. Make sure you sudo
the commands if you're not root:
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=4096
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1
Composer takes alot of memory for certain repositories like Drupal.
Essentially, this creates 4 GB of Swap memory from the hard drive which the CPU can use to complete the composer command.
The original solution seems to have come from this Github thread but I could be mistaken:
https://github.com/composer/composer/issues/7348#issuecomment-414178276
To load the swap at boot add the following line in /etc/fstab
/var/swap.1 none swap sw 0 0
You may want to backup your fstab
file just to be on the safe side.
To reclaim the swap space do this:
sudo swapoff -v /var/swap.1
sudo rm /var/swap.1
If you get a message like this after turning on the swap...
swapon: /var/swap.1: insecure permissions 0644, 0600 suggested.
...change the permission if appropriate
sudo chmod 600 /var/swap.1
Memory limit errors
Composer may sometimes fail on some commands with this message:
PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...> Or in my case : Fatal error: Out of memory (allocated 1116733440) (tried to allocate 134217728 bytes) in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/DependencyResolver/Pool.php on line 339
In this case, the PHP memory_limit should be increased.
Note: Composer internally increases the memory_limit to 1.5G.
To get the current memory_limit value, run:
php -r "echo ini_get('memory_limit').PHP_EOL;"
Try increasing the limit in your php.ini file (ex. /etc/php5/cli/php.ini for Debian-like systems):
; Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1
Composer also respects a memory limit defined by the COMPOSER_MEMORY_LIMIT environment variable:
COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>
Or, you can increase the limit with a command-line argument:
php -d memory_limit=-1 composer.phar <...>
This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the documentation of the fork bomb feature on the cPanel site.
To get loaded php.ini files location try:
php --ini
Source : (Composer docs)
It's a memory problem, not a storage issue. You are reaching your PHP memory limit.
Edit /etc/php.ini and increase the memory limit ( memory_limit = 128M replace with memory_limit = 256M )
I would suggest you look for the reason composer is using so much memory , and find ways to cut your PHP memory usage :
Upgrade to PHP56 if you haven't already Install Zend Opcache ( shares PHP memory between different instances ) Uninstall any and all unused PECL extensions
This is the issue you are having : https://github.com/composer/composer/issues/1898
Try this one
COMPOSER_MEMORY_LIMIT=-1 composer require [package name]
I'm on a Windows machine and I tried all of the answers from this question, but none of them worked. For me, it FINALLY worked after I ran composer using the 64-bit version of PHP.
To run composer using a local copy of PHP x64 you can do the following:
Download the zip file from here (I used the VC15 x64 Thread Safe version): https://windows.php.net/download Unzip the file Copy php.ini-development and rename to php.ini Uncomment the extension_dir = "ext" line and any other php extensions you will need (such as extension=gd2 or extension=openssl). If any other PHP extensions are needed for the update then it will tell you while running the command.
Working command:
"C:\path\to\php-7.2.23-Win32-VC15-x64\php.exe" -d memory_limit=-1 "C:/path/to/composer.phar" update
When using the software Laragon on Windows, the following line helped me requiring a new package without getting the memory error:
php -d memory_limit=-1 "C:\laragon\bin\composer\composer.phar" require <insert package author here>/<insert package name here>
The solution that works both on local environment but also in a container (e.g. in a build stage of a pipeline) where composer might be installed in tricky way, is
COMPOSER_MEMORY_LIMIT=-1 composer install
php -d memory_limit=-1 /usr/local/bin/composer install
This command work for me.
In my case, I was facing this error because of running composer install
inside vagrant box. Running it inside my host machine didn't cause the issue.
Nothing worked for me except putting memory_limit = -1
in php.ini
file.
I set memory_limit=-1 in my php.ini file but didnt work but i went ahead to execute commands from link below and then run composer install and worked perfectly
https://tecadmin.net/enable-swap-on-ubuntu/
It worked for me!
Download the zip 64-bit version of your PHP from this link: https://windows.php.net/download/
https://i.stack.imgur.com/72Kqg.png
Now extract it to C:\PHP-74\ and rename the php.ini-development to php.ini
https://i.stack.imgur.com/Iruni.png
Now open this php.ini and uncomment the following by removing ; (semicolon).
extension_dir = "ext"
extension=bz2
extension=curl
extension=fileinfo
extension=gd2
extension=gettext
extension=mbstring
extension=exif ; Must be after mbstring as it depends on it
extension=mysqli
extension=openssl
extension=pdo_sqlite
In my scenario these extensions are required you can compare your old php.ini file of xampp or wamp resolve this one. Now save the file and run the following command.
"C:\PHP-74\php.exe" -d memory_limit=-1 "C:\ProgramData\ComposerSetup\bin\composer.phar" update
Update composer to v2.
composer self-update --2
Remove vendor path and composer.lock file.
Set in php.ini memory_limit=-1
.
Run
composer install
This one helped me, with showing memory usage:
php -d memory_limit=-1 /usr/local/bin/composer update --verbose --profile
You may also get resolved by just removing vendor directory and re-execute composer install command.
Try increase the memory_limit value in your active php.ini file.
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 512M
For example.
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.
php -d memory_limit=-1 /usr/local/bin/composer update --no-scripts
memory_limit=-1
is for unlimited memory for this process when you add php before the composer for unlimited memory then you have to give composer complete path where its installed on server (for ubntu) its /usr/local/bin/composer
Reamining part is just compoer commands update/install
Increasing the memory_limit
value on my php.ini
did not solve my problem. What I did was:
Delete composer.lock, run composer update,
And that did the trick!
If you are still facing issues after updating your memory limit then the best thing to try is to run:
composer update --lock
This will update your lock file so that composer can run from it if you have changed your composer.json file.
You can now optimally run:
composer update
or
composer install
If on Windows, using XAMP, I recommend to Update your Composer version to latest. Uninstall, download latest - https://getcomposer.org/download/ and install.
Could also try update PHP version to latest.
If you are running into composer memory problems, now your best option is probably to use composer v2, if you can.
Composer v2 has many performance improvements and as a result, it takes much less memory.
I was always having to use COMPOSER_MEMORY_LIMIT=-1 composer update
but after the v2 update, I no longer need to use this.
Check out the release announcement https://blog.packagist.com/composer-2-0-is-now-available/ or download the latest version https://getcomposer.org/download/
sudo php -d memory_limit=-1 bin/magento setup:di:compile
Success story sharing
which composer update