Error installing CLI packages - Fatal error: Allowed memory size exhausted

Issue Summary

I’m trying to install some CLI packages we use on our staging/production servers but it keeps failing.

The main one I’m trying to use using is:

wp package install

Though I get the same issue with others.

Here’s the exact trace/error:

    Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 42824584 bytes) in phar:///Applications/ on line 461

Call Stack:
    0.0017     396824   1. {main}() /Applications/
    0.0382    2203024   2. include('phar:///Applications/') /Applications/
    0.0384    2204264   3. include('phar:///Applications/') phar:///Applications/
    0.0388    2207688   4. WP_CLI\bootstrap() phar:///Applications/
    0.2580    4866440   5. WP_CLI\Bootstrap\LaunchRunner->process() phar:///Applications/
    0.2580    4866480   6. WP_CLI\Runner->start() phar:///Applications/
    0.2584    4866744   7. WP_CLI\Runner->do_early_invoke() phar:///Applications/
    0.2585    4867896   8. WP_CLI\Runner->run_command_and_exit() phar:///Applications/
    0.2586    4867896   9. WP_CLI\Runner->run_command() phar:///Applications/
    0.2587    4869072  10. WP_CLI\Dispatcher\Subcommand->invoke() phar:///Applications/
    0.2644    5021064  11. call_user_func:{phar:///Applications/}() phar:///Applications/
    0.2644    5021064  12. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure:phar:///Applications/}() phar:///Applications/
    0.2644    5021912  13. call_user_func:{phar:///Applications/}() phar:///Applications/
    0.2644    5021912  14. Package_Command->install() phar:///Applications/
    0.6233    7242840  15. Composer\Installer->run() phar:///Applications/
    0.6257    6672976  16. Composer\Installer->doInstall() phar:///Applications/
    4.6869    9377488  17. Composer\Installer->processDevPackages() phar:///Applications/
    5.4592  206084032  18. Composer\DependencyResolver\Pool->whatProvides() phar:///Applications/
    5.4593  206084072  19. Composer\DependencyResolver\Pool->computeWhatProvides() phar:///Applications/
    5.4593  206084072  20. Composer\Repository\ComposerRepository->whatProvides() phar:///Applications/
    5.4593  206084296  21. Composer\Repository\ComposerRepository->fetchFile() phar:///Applications/
    5.4595  206084520  22. Composer\Util\RemoteFilesystem->getContents() phar:///Applications/
    5.4595  206084520  23. Composer\Util\RemoteFilesystem->get() phar:///Applications/
    5.6372  207141256  24. zlib_decode() phar:///Applications/


Try installing the package above. Maybe it’s specific to my system?

System Details

  • Which version of Local is being used?


  • What Operating System (OS) and OS version is being used?

macOS 11.3 Big Sur

  • Attach the Local Log. See this Community Forum post for instructions on how to do so:

local-lightning.log (104.3 KB)

I’m able to install that package on my system (macOS Catalina).

While doing some googling, I found this issue related to M1 Macs:

I notice you’re on BigSur – do you have one of the newer M1 macs?

I’m on an old MacBook, not even close to the M1’s. I had a suspicion it was something specific to my system, and if that’s really the case I’m even more depressed since I struggle with terminal and tooling in general so it seems unlikely I’ll be able to fix it anytime soon.

Worth noting I bumped the memory_limit too, and still get the same issue.

max_execution_time = 1200
max_input_time = 600
max_input_vars = 4000
memory_limit = 1024M
post_max_size = 1000M
max_file_uploads = 20
output_buffering = 4096

Do you have other composer packages installed? That error mentions a memory size of 268435456 which is just a touch over a typical default limit of 256M – I wonder if there’s some other default memory setting that is being referenced somewhere.

Also, that stack trace appears to be referencing Local’s version of wp-cli – so I think that the shell is configured correctly, but just to double check, let’s see what version of PHP and wp-cli is being used. Within that site shell, can you run these commands:

which php; php --version; which wp; wp --version
echo $SHELL; echo $PATH | tr ':' '\n'

What we’re looking for is to verify that there isn’t some other path pollution happening, for example, some other configuration of PHP, or perhaps a global composer configuration.

Here’s what mine looks like:

Hey Ben, thanks so much for helping with this.

Here’s what I get.

PHP 7.3.5 (cli) (built: Jul 24 2020 21:39:21) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.5, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.9.0, Copyright (c) 2002-2019, by Derick Rethans
WP-CLI 2.5.0-alpha

That all looks pretty standard.

Do you have a bunch of wpcli packages already installed? I think you can check that by running this command:

wp package list

Interesting. I have one leftover from my time testing Laravel Valet, which I no longer need or use.

| name                             | authors      | version    | update    | update_version |
| aaemnnosttv/wp-cli-valet-command | Evan Mattson | dev-master | available | dev-master     |

If you don’t need it, maybe it’s worth a try to remove it?

Hmmm, my first time actually removing a package.

wp package uninstall aaemnnosttv/wp-cli-valet-command
Removing require statement from /Users/JiveDig/.wp-cli/packages/composer.json
Removing repository details from /Users/JiveDig/.wp-cli/packages/composer.json
Removing package directories and regenerating autoloader...

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 42841896 bytes) in phar:///Applications/ on line 461

I’ve never removed a package like that either, but it should be similar to removing one with composer (that’s what wpcli uses under the hood).

I forgot to ask and continue investigating this line of thought… how and where did you make this change? Did you verify that the settings were applied?

I read this FAQ within the wpcli handbook:

The above link mentions that there might be an additional php.ini file. This isn’t something that Local would put in place, but maybe if this site has been imported from another host, there would be an additional file. Here’s the general workflow I would try:

  1. Update the values for the site within ~/Local Sites/sitename/conf/php/php.ini.hbs
    • Any changes you make to this site configuration, need to include a restart of the site in Local (stop site, and then start again). This is so Local can re-compile the .hbs file into the actual running configuration for the site.
    • Try installing your package again after doing this
  2. Find additional php.ini files. Right-click on the site in Local and select “Open Site Shell”
    • Within the shell, use this find command:
    find . -name 'php.ini'
  3. Try installing the package by increasing memory at runtime. I found this in the above linked FAQ doc:
    php -d memory_limit=512M "$(which wp)" package install <package-name>
    • You might need to go quite high. Depending on how much ram you have, I’d keep increasing that limit to 1024M, 2048M or more!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.