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

autoload_classmap.php file empty after running composer commands #5707

Closed
davorminchorov opened this issue Sep 23, 2016 · 32 comments

Comments

@davorminchorov
Copy link

commented Sep 23, 2016

Hey,

I work on a Laravel project and whenever I run composer install / update, dump-autoload or any php artisan commands, everything works fine for the first time, but when I run another composer / artisan command after that, I get the following error:

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Composer\Autoload\ClassLoader::addClassMap() must be of the type array, integer given, called in /var/www/html/vendor/composer/autoload_real.php on line 38 and defined in /var
/www/html/vendor/composer/ClassLoader.php:91
Stack trace:
#0 /var/www/html/vendor/composer/autoload_real.php(38): Composer\Autoload\ClassLoader->addClassMap(1)
#1 /var/www/html/vendor/autoload.php(7): ComposerAutoloaderInitab0ba58f39538bb9f0cac5f548fa5488::getLoader()
#2 /var/www/html/bootstrap/autoload.php(17): require('/var/www/html/v...')
#3 /var/www/html/artisan(16): require('/var/www/html/b...')
#4 {main}
  thrown in /var/www/html/vendor/composer/ClassLoader.php on line 91

Fatal error: Uncaught TypeError: Argument 1 passed to Composer\Autoload\ClassLoader::addClassMap() must be of the type array, integer given, called in /var/www/html/vendor/composer/autoload_real.php on line 38 and defined in /var/www/
html/vendor/composer/ClassLoader.php:91
Stack trace:
#0 /var/www/html/vendor/composer/autoload_real.php(38): Composer\Autoload\ClassLoader->addClassMap(1)
#1 /var/www/html/vendor/autoload.php(7): ComposerAutoloaderInitab0ba58f39538bb9f0cac5f548fa5488::getLoader()
#2 /var/www/html/bootstrap/autoload.php(17): require('/var/www/html/v...')
#3 /var/www/html/artisan(16): require('/var/www/html/b...')
#4 {main}
  thrown in /var/www/html/vendor/composer/ClassLoader.php on line 91

I noticed that the autoload_classmap.php file is empty, so for a quick temporary fix, I deleted the composer folder and just run composer install.

I've deleted the vendor folder completely and rerun composer install but that seems to work temporary. I still get the same error on the second composer / artisan command.

I am using PHP 7.0.10 and Vagrant + Docker as my environment. I use a local composer.phar file inside the application container.

When I run composer self-update I get:

You are already using composer version 1.2.1 (stable channel).

The weird part is that my colleague is using the same docker environment and he doesn't have this problem. Also, this happens to this project only.

If you need any more information, let me know.

Any ideas what might be the problem?

@SergeySetti

This comment has been minimized.

Copy link

commented Sep 25, 2016

The same issue, the same environment and framework.
PHP 7.0.11, Composer 1.2.1

@SergeySetti

This comment has been minimized.

@SergeySetti

This comment has been minimized.

Copy link

commented Sep 25, 2016

The best solution for now - downgrading to Composer 1.2.0

@davorminchorov

This comment has been minimized.

Copy link
Author

commented Sep 25, 2016

I'll try to downgrade it but how can I do that?

@SergeySetti

This comment has been minimized.

Copy link

commented Sep 25, 2016

@Rufflesaurus , just composer self-update 1.2.0
Or you can replace your composer bin with https://getcomposer.org/download/1.2.0/composer.phar

@alcohol

This comment has been minimized.

Copy link
Member

commented Sep 26, 2016

Do you have a way to reproduce this without artisan? I'm not going to install laravel global plugins just to get this working. If you do not have any other way to reproduce this, then I think we can conclude that this is not a composer bug, but a laravel bug instead.

@alcohol alcohol added the Support label Sep 26, 2016

@davorminchorov

This comment has been minimized.

Copy link
Author

commented Sep 26, 2016

I think it's hard to reproduce this problem because it only happens from time to time, usually when the composer dump-autoload -o is running. It also happens when I install a new package / do an update for new packages.

It's ok for now, I'll report back if it happens again.

@Seldaek

This comment has been minimized.

Copy link
Member

commented Sep 29, 2016

OK closing this for now but please come back to us with details if you find a way to reproduce it reliably. Downgrading to 1.2.0 is not a solution btw, if downgrading really helps, then we need to figure out what broke in 1.2.1 and fix it.

@Seldaek Seldaek closed this Sep 29, 2016

@coldlamper

This comment has been minimized.

Copy link

commented Sep 30, 2016

I can reproduce an empty autoload_classmap.php file using

{
    "require": {
          "authorizenet/authorizenet": "~1.8"
    }
}

for composer.php
and Composer v1.2.1 and PHP 7.0.8

@Seldaek

This comment has been minimized.

Copy link
Member

commented Oct 1, 2016

@coldlamper what version do you get installed? Because 1.8.0 has no autoload definitions at all, so that doesn't mean anything.

@coldlamper

This comment has been minimized.

Copy link

commented Oct 4, 2016

I think it's 1.8.9

@alcohol

This comment has been minimized.

Copy link
Member

commented Oct 4, 2016

I think it's 1.8.9

It would be nice if you could take the time to check and confirm. Cause the difference is quite significant.

@coldlamper

This comment has been minimized.

Copy link

commented Oct 4, 2016

Sorry it is installing 1.8.0. I believe it should be installing 1.8.9, correct?

@Seldaek

This comment has been minimized.

Copy link
Member

commented Oct 5, 2016

1.8.9 has a bunch of requirements like it needs ext-xmlwriter and ext-simplexml, maybe you don't have those so it is downgrading to 1.8.0 which does not have the requirements. Try requiring 1.8.9 explicitly and it should tell you why it is not installable.

@coldlamper

This comment has been minimized.

Copy link

commented Oct 5, 2016

Using "authorizenet/authorizenet": "1.8.9"

Problem 1
    - Installation request for authorizenet/authorizenet 1.8.3.3 -> satisfiable by authorizenet/authorizenet[1.8.3.3].
    - authorizenet/authorizenet 1.8.3.3 requires php ~5.3 -> your PHP version (7.0.8) does not satisfy that requirement.
@stof

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2016

next step: contact the authorizenet maintainers to ask them to allow installing their package on PHP 7 (their PHP requirement tells composer that it cannot be used on PHP 7)

@alcohol

This comment has been minimized.

Copy link
Member

commented Oct 6, 2016

For now you can get around this by using the --ignore-platform-reqs flag.

@davorminchorov

This comment has been minimized.

Copy link
Author

commented Oct 6, 2016

It looks like the problem is back once I ran composer update to update the packages. Before that, I tried running composer dump-autoload -o just to see if it will fail again, but it was magically fixed for some reason.

I didn't use any commands for a few days and just before I started using them again I ran composer update and something brought the problem back.

Still trying to figure out what might be causing the problem but I have a hard time reproducing it so you can test it on your own.

@jural

This comment has been minimized.

Copy link

commented Nov 2, 2016

I had the same error. I think it is not related to composer.

My configuration is: Windows host, vagrant with Debian quest and nfs sharing enabled, composer 1.2.1.
I debugged this and noticed that composer in src/Composer/Autoload/AutoloadGenerator.php:273 wants to save content to existing file autoload_classmap.php:

file_put_contents($targetDir.'/autoload_classmap.php', $classmapFile);

After this operation (called with success) content of this file is still empty. I removed this file (vendor/composer/autoload_classmap.php) and call again composer.phar dump-autoload. File was created with content and problem was solved.

I think problem is related to permissions of this file or problems with sharing files between host -> quest in vagrant... I hope I will help someone :)

@davorminchorov

This comment has been minimized.

Copy link
Author

commented Nov 4, 2016

@jural I tried deleting all of the autoload files inside the composer folder and running composer dump-autoload -o as you suggested but the problem is still there.

@spiritix

This comment has been minimized.

Copy link

commented Nov 16, 2016

I can confirm this problem, multiple of our developers faced it within the last weeks. Sometimes we could solve it by deleting the autoload_classmap.php file, sometimes by reloading Vagrant, sometimes we couldn't get it working at all. It's not a Laravel problem, it's caused by Vagrant on Windows, specifically by the winnfsd/vagrant-winnfsd plugin. The file_put_contents in src/Composer/Autoload/AutoloadGenerator.php:273 mentioned by @jural does actually work, it returns the number of written bytes like expected. However, the file is still empty after the write operation finishes. This confirms the whole problem being related to the underlying file system. If you configure composer to keep the vendor dir outside of the scope managed by winnfsd ("vendor-dir": "~/composer/"), everything works fine. The winnfsd plugin is known for being quite buggy in general, so I don't think something in composer can be done to solve this problem.

@luispabon

This comment has been minimized.

Copy link

commented Jan 11, 2017

Not a vagrant problem, I just got this running native on Linux and PHP 7.1.

@andrei930

This comment has been minimized.

Copy link

commented Feb 25, 2017

In my case (using Homestead) this seems to be fixed by removing type: "nfs" from the folders section in Homestead.yaml.

@spiritix

This comment has been minimized.

Copy link

commented Feb 25, 2017

@andrei930 Yes that solves the problem, but without NFS the VM is significantly slower, so that's not really a solution.

@andrei930

This comment has been minimized.

Copy link

commented Feb 27, 2017

Apparently I was using an outdated version of vagrant-winnfsd. For me it's fixed by updating to the latest version (1.3.1).
Edit: Nevermind, it still fails after a while (?). A workaround is to halt the machine, kill the NFS server and start the vagrant again.

@YOzaz

This comment has been minimized.

Copy link

commented Apr 5, 2018

Anybody found a "proper" solution for this? Halting / killing is kind of hacky.

@spiritix

This comment has been minimized.

Copy link

commented Apr 5, 2018

You can try to use SMB instead of NFS, I am not really aware of the consequences though. Otherwise, I am happy to share the script we ended up with you guys:

#!/usr/bin/env bash

vagrant halt
cmd "/C TASKKILL /IM winnfsd.exe /F";
vagrant up
vagrant ssh

Just put that in a bash file on your host machine and execute it once NFS crashed.
Still a hackish solution, but what shall we do :)

@YOzaz

This comment has been minimized.

Copy link

commented Apr 5, 2018

@spiritix that's exactly what we're doing as well, but I thought maybe winnfsd developers came up with a better solution.
Alternative option would be composer dumpautoload (without optimize flag).
It's a clearly NFS mount problem (I've tried experimenting with NFS mount option, which helped a little), as it looks like it runs out of memory?
Non-NFS mount is not an option I think, it would be the same as downgrading to Windows 98 just because Windows 10 freezes once in a month.

@spiritix

This comment has been minimized.

Copy link

commented Apr 5, 2018

@YOzaz Already reported that to the winnfsd developers (winnfsd/vagrant-winnfsd#104), maybe you could file an issue as well.

@huasio

This comment has been minimized.

Copy link

commented May 16, 2018

@spiritix Damn, I also encountered this problem, based on your recommended solution, is in the local new bash file, the script writing, run it, as I so, operation is still running NFS.

@jartaud

This comment has been minimized.

Copy link

commented May 29, 2018

@szlwl what?

@jantomicky

This comment has been minimized.

Copy link

commented Aug 19, 2018

Had the exact same problem.

Windows 10, Version 1803, Build 17134.228
Vagrant 2.1.0
VirtualBox 5.2.12
WinNFSd 1.3.1
Laravel Homestead (not sure about the version, probably 7.6, but it shouldn't really matter).

Not using NFS isn't really a solution for me, as it increases page load times from ~2 sec to ~10 sec, sometimes even more.

Seems to be solved by setting these NFS mount options:

mount_options: ['rw,vers=3,udp,nolock,actimeo=2']

I hear that UDP isn't ideal, but it works; on TCP the VM would just freeze on me after ~15 minutes of inactivity, never to recover.

BTW, another and probably related issue, after running gulp three and more times to minimize the JavaScript sources, I got a 0 byte file as a result along with a NFS server error No such file or directory IO as mentioned here: winnfsd/vagrant-winnfsd#104 (comment) and only reloading vagrant & the NFS server solved it. Turned out to be an issue with Windows Defender, probably an exclusive file lock / race condition issue.

Excluding the whole synchronized folder from the Windows Defender "workspace" seems to do the trick, at least up till now it has – might work in this case for you too.

Also, since then I updated all the tools to their current versions (Vagrant 2.1.2, VirtualBox 5.2.16, WinNFSd 1.4.0, Homestead 7.14.2) and now I'm having zero issues, so I recommend updating everything too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.