PHP built-in server crashes when performing certain actions on Nextcloud #9396
Description
This is more a curiosity than something that needs to be fixed (as nobody would use the PHP built-in web server to run Nextcloud in the real world, and the bug is triggered by Nextcloud, but it does not look like a Nextcloud bug), but I thought it was worth documenting it.
In the last days the acceptance tests for the Files app have been failing. Specifically, the add tags using the dropdown in the details view and remove tags using the dropdown in the details view scenarios. However, if you performed the actions from those scenarios manually on a real web server everything worked fine. Why did they fail on Drone then?
Well, they failed because the PHP built-in web server crashed (SIGSEGV). Really :-P That crash was not related to Drone nor the acceptance tests, though; it can be reproduced with the steps below:
- Create a Docker container for the PHP built-in server
- On a Nextcloud Git directory, checkout the first offending commit with
git checkout 09940bcde6 && git submodule update --recursive - Start a Docker container for the Nextcloud server in that directory with
docker run --rm --volume /PATH/TO/THE/NEXTCLOUD/GIT/DIRECTORY/:/var/www/html --volume /var/www/html/data --volume /var/www/html/config --interactive --tty --name php-builtin-server-crash nextcloudci/php7.1:php7.1-16 bash - In a different terminal (as the previous one will be in the Bash session inside the container), get the IP of the new container with
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' php-builtin-server-crash
- On a Nextcloud Git directory, checkout the first offending commit with
- Start the PHP built-in server (all the following commands are performed in the Bash session inside the container)
- Change to the Nextcloud directory with
cd /var/www/html - Install Nextcloud with a SQLite database with
php occ maintenance:install --admin-pass=admin - Whitelist the IP of the container with
php occ config:system:set trusted_domains 0 --value="IP_OF_THE_CONTAINER" - Start the PHP built-in server with
php -S IP_OF_THE_CONTAINER:80 -t .
- Change to the Nextcloud directory with
- Make the PHP built-in server crash
- Visit http://IP_OF_THE_CONTAINER in a web browser
- Login as admin with password admin
- Open the settings, and then the Workflow section
- Create a tag named tag1
- Create a tag named tag2
- Show the list of tags
When the list of tags is shown the image http://IP_OF_THE_CONTAINER/core/img/actions/search.svg is loaded, and that is what causes the crash. It is not a problem of the image, though; loading any other resource (anything that does not start with index.php, like images, CSS files, or even just http://IP_OF_THE_CONTAINER/core or http://IP_OF_THE_CONTAINER/apps) causes the crash, but it does not happen if http://IP_OF_THE_CONTAINER/index.php is loaded instead.
Moreover, the crash requires a resource to be loaded immediately after creating two or more tags in a row; it does not happen if just one tag is added and a resource is loaded, or if one tag is added, a resource is loaded, another tag is added, and then another resource is loaded.
Finally, the crash happens when using the Docker images for PHP 7.1 (nextcloudci/php7.1:php7.1-16) and PHP 7.2 (nextcloudci/php7.2:php7.2-11), but not in PHP 7.0 (nextcloudci/php7.0:php7.0-19).
The first offending commit was 09940bc, and it was magically fixed in d40afac.
Most plausible explanation to all this seems to be A wizard did it.