zlib_decode(): data error #5814
Comments
|
The problem seems to appear on this line https://github.com/composer/composer/blob/1.2.1/src/Composer/Util/RemoteFilesystem.php#L388 |
|
Error is reproducible with all |
|
Please search existing issues for possible solutions. This is not a Composer issue but an environment issue. |
|
@alcohol not sure it's just an environment issue, because composer Have searched over the tickets, those are related: |
|
Unless you can provide a way for me to reproduce it consistently, it is most definitely an environment issue. |
|
@alcohol this fixed my issue: #4121 (comment). So basically forcing The issue was happening in Vagrant boxes, with any kind of php or composer version. Using https://gist.github.com/radutopala/8761ac647ee165d373b0c6d727cd56ea, intermittently I got from 1 to 20 retries until successful decoding the gzip. |
|
Let me guess, using a shared directory also with your host system? |
|
@alcohol yes |
|
What happens if you run it inside vagrant, without a shared directory? E.g. purely inside the vagrant box, storage inside the vagrant box too. |
|
@alcohol apparently the same error: So it doesn't matter where the test is taken, either in shared folder or in an internal box folder. For what is worth mentioning, I have VirtualBox |
|
Not really worth mentioning since we do not maintain virtualbox nor vagrant (though I doubt vagrant is at fault here, likely virtualbox). |
|
Well .. even though composer maintainers are not tight to VirtualBox nor vagrant, other users may come across the same issue I had. I just discovered that VirtualBox And vagrant nicely downgraded VirtualBox to Now the test is decoding correctly the gzip-ed content every time: So .. the solution is to let vagrant install the right VirtualBox version. |
|
Just in case somebody is redirected here because of the I confirm the bug is related to VirtualBox, either I had the same problem in 3 different machines, macOS 10.10 and 10.12. I did many tests, create clean VM instances of Laravel Homestead and installing the Laravel framework, forcing IPv4 in the VM, disabling ssl verification of packagist, etc... Nothing worked until I downgraded to 5.0.26. |
|
downgrading to 5.0.26 also works on OSX 10.11.6 |
|
@radutopala Brilliant! Indeed it is VirtualBox. @jaumesala Great work pinpointing the latest specific VirtualBox version that does not exhibit this problem! I just tried downgrading to VirtualBox 5.0.26 and sure enough, the problem no longer occurs. You two spared me hours of further frustration, and I deeply appreciate it. Given that this does not seem to be a problem with Composer, I opened a thread on the VirtualBox forums. If nobody can offer a viable solution there, I'll open an actual bug report with VirtualBox. https://forums.virtualbox.org/viewtopic.php?f=3&t=80396&p=376826 It would be helpful if other folks could visit the above thread and chime-in with guest OS version and any other information that might be useful to the VirtualBox developers. |
|
I had this error on Homestead image with Vagrant 1.8.1 and Virtual box 5.1.8 on Mac Os. Downgrading to Virtualbox 5.0.26 and composer update completes without a problem. |
|
Hi, I had the same problem. Downgrading VirtualBox from 5.1.8 to 5.1.6 helped. |
|
Same here there is definitely an issue with the latest virtual box and shared nfs folders. |
|
I encountered this issue today with the exact same setup as @udaiveerS. Downgrading VirtualBox to 5.1.6 solved it for me also. |
|
@mihhac @thats4shaw Good to know that 5.1.6 is the latest version of the 5.1 branch that doesn't suffer from this problem. Does anyone have the networking expertise to chime-in on the VirtualBox thread at https://forums.virtualbox.org/viewtopic.php?f=3&t=80396&p=376826 ? That would be hugely helpful to the rest of us. :) |
|
@cbj4074 it's highly unlikely you will find such people here 😆 , but if you give VirtualBox guys a way to reproduce this issue, they'll figure it out themselves. Start by specifying your host and guest operating systems, then either use a prebuilt virtual machine available online or specify you installed it from an image. After that add the commands they need to run to get php and the test script running on the box and what the expected and actual outcomes are. |
|
@Ingramz Thanks! All great advice. Maybe I can dedicate a couple of hours to this today. I would really like to eliminate PHP from the equation entirely. Maybe it is a distraction from the underlying issue. If we could simply demonstrate that files cannot reliably be "gunzipped", regardless of their source, that would be ideal. But maybe PHP is part of the problem. I do find it curious that the OS itself wouldn't barf in the nearest trash can if gunzipping failed across-the-board. Presumably gzip is used all over the place, from the package manager to log-rotation. |
|
@cbj4074 as far as I know it doesn't matter what you give them, the first thing they will look at are recent changes by performing a binary search on the commits. They probably know better themselves where to look after that. |
|
Maybe it's worth taking a look at the strace output of the test script: https://gist.github.com/magnetik/82a9d1d9c34401b6268ba07a949cc491#file-strace-txt Looking at the end, it only looks like the connection is interrupted ?. |
|
@magnetik can you reproduce that consistently though? |
|
When running the script in the gist, the first 3-20 tries fails. Not consistently. I'm using sury PPA |
|
What do you mean, except for the last one? It has an |
|
I've edited my answer since it was not clear enough. Sometimes it decodes successfully after 3 tries, sometimes after 20 tries. I've logged the output of the I've added the log in the gist : |
|
Can you try running your script against |
|
That damn peer.. Does it consistently reset the connection? I updated the |
|
5 requests fails over 20. |
|
And on my host? |
|
Same, maybe a little less, I had 3 fails in 35 requests |
|
Weird, unable to reproduce it myself. I see all your requests and they all seem to succeed (assuming the connection reset occurs after connecting). I count 56 requests. |
|
When using curl directly, I've always the same size : Given that virtualbox 5.1.6 did not had the issue, it should be something on that side that is closing the connection too early. |
|
curl by default doesn't use gzip though for example, and maybe other parameters are different. At least try with |
|
I've an answer from virtualbox, and it seems to be on their side : https://forums.virtualbox.org/viewtopic.php?f=3&t=80396#p377627 Thanks for the input that allowed to pinpoint the issue on their side. Let's continue the discussion there. |
|
I had the same problem. Fixed downgrading VirtualBox to Version 5.0.26. Some contributor should add this solution more visible in the issue #4121 (comments are closed). Google points your first to the other issue. |
|
At least we can reference #4121 here. |
|
Issue is fixed for me for the to be released Virtualbox 5.1.9. You can try it yourself with Virtualbox test build > 111846 https://www.virtualbox.org/wiki/Testbuilds |
|
@magnetik, confirmed it myself as well. VirtualBox 5.1.9 development build resolved my issue. Thanks everyone! |
Virtualbox has some buggy releases that break some network junk. See [this composer issue](composer/composer#5814) for an example.
|
Jesus christ! VirtualBox 5.0.28 should be eliminated from Earth. Thank Oracle. |
|
@hectornguyen Virtualbox had a bug breaking HTTP traffic using Gzip. |
|
This is now working fine for me after upgrading to VirtualBox 5.0.30, so it looks like Oracle have fixed it now. |
|
Virtualbox 5.0.30 r112061 worked well in my case... |
|
Virtualbox 5.1.14 r112924 (currently the latest release) works too |
|
Im still having this issue with 5.1.22 r115126 on windows host |
My
composer.json:{ "name": "test/test", "license": "proprietary", "type": "project", "autoload": { "psr-4": { "": "src/" }, "classmap": [ "app/AppKernel.php", "app/AppCache.php" ] }, "autoload-dev": { "psr-4": { "Tests\\": "tests/" } }, "require": { "php": ">=7.0.11", "symfony/symfony": "3.1.*", "doctrine/orm": "^2.5", "doctrine/doctrine-bundle": "^1.6", "doctrine/doctrine-cache-bundle": "^1.2", "doctrine/doctrine-migrations-bundle": "^1.1", "symfony/swiftmailer-bundle": "^2.3", "symfony/monolog-bundle": "^2.8", "symfony/assetic-bundle": "^2.8", "symfony/polyfill-apcu": "^1.0", "sensio/distribution-bundle": "^5.0", "sensio/framework-extra-bundle": "^3.0.2", "incenteev/composer-parameter-handler": "^2.0", "snc/redis-bundle": "2.x-dev", "predis/predis": "^1.0", "lexik/jwt-authentication-bundle": "^1.5", "tss/automailer-bundle": "dev-master", "knplabs/knp-paginator-bundle": "^2.5", "fabpot/goutte": "^3.1", "whiteoctober/breadcrumbs-bundle": "^1.2", "spraed/pdf-generator-bundle": "^1.3", "vich/uploader-bundle": "1.2.0", "friendsofsymfony/jsrouting-bundle": "^1.6", "gregwar/captcha-bundle": "^2.0", "liip/imagine-bundle": "^1.6", "knplabs/knp-menu-bundle": "^2.0", "fabpot/php-cs-fixer": "^1.12", "symfony/serializer": "^3.1", "jms/serializer": "^1.3", "jms/serializer-bundle": "^1.1" }, "require-dev": { "sensio/generator-bundle": "^3.0", "symfony/phpunit-bridge": "^3.0" }, "scripts": { "post-install-cmd": [ "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-update-cmd": [ "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" ] }, "extra": { "symfony-app-dir": "app", "symfony-bin-dir": "bin", "symfony-var-dir": "var", "symfony-web-dir": "web", "symfony-tests-dir": "tests", "symfony-assets-install": "relative", "incenteev-parameters": { "file": "app/config/parameters.yml" } } }Output of
composer diagnose:When I run this command:
I get the following output:
And I expected this to happen:
Expected to update the
composer.lockThe text was updated successfully, but these errors were encountered: