|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2018-04-10 17:02 UTC] post at minhost dot no
Description: ------------ After upgrading our shared hosting servers from PHP 7.1.15 to PHP 7.1.16, some users running Infinitewp to update their WordPress sites experience that when they do "Reload data" in Infinitewp, then some of their WordPress sites go down with this error: "HTTP Error 503: Service Unavailable - The request was not completed. The server is temporarily overloading or down." And PHP-FPM is down on those sites. This never happen in previous PHP 7.1.15 To get the sites up and running again, I need to reload php-fpm71 In Apache error log we get errors like this: [Tue Apr 10 17:12:06.695643 2018] [proxy_fcgi:error] [pid 31674:tid 139648101607168] [client 194.242.11.18:56034] AH01067: Failed to read FastCGI header, referer: https://domain.tld/?no_cache_KFoZ4ai5=1523373126 [Tue Apr 10 17:12:06.695691 2018] [proxy_fcgi:error] [pid 31674:tid 139648101607168] (104)Connection reset by peer: [client 194.242.11.18:56034] AH01075: Error dispatching request to : , referer: https://domain.tld/?no_cache_KFoZ4ai5=1523373126 In /usr/local/php71/var/log/php-fpm.log I get this: [10-Apr-2018 17:12:06] WARNING: [pool sommerfr] child 24746 exited on signal 11 (SIGSEGV) after 8409.340823 seconds from start [10-Apr-2018 17:12:06] NOTICE: [pool sommerfr] child 17221 started Please note that I am running both normal opcache in memory, and also has opcache on disk as a fallback cache (to be used whenever opcache get empty during restarts). Here is my ini settings: opcache.memory_consumption=32768 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=1000000 opcache.revalidate_freq=0 opcache.validate_timestamps=1 opcache.fast_shutdown=1 opcache.enable_cli=0 opcache.validate_permission=1 opcache.validate_root=1 opcache.use_cwd=1 opcache.revalidate_path=1 opcache.enable_file_override=1 opcache.file_cache_only=0 opcache.max_wasted_percentage=10 One thing I suspect could play a role, is that all the sites that went down after running "Reload data" in Infinitewp, had one thing in common, that is: Nobody had visited WordPress dashboard on those sites, so at: /home/USER/.opcache/0d01841927accbb2865ecf61ea43a8ce/home/USER/domains/DOMAIN.TLD/public_html/wp/wp-admin There was only 1 directory and 2 files, when I manually visited WordPress dashboard, several more files where added in opcache on that path. So maybe the bug only happen if disk based opcache have not yet cached all needed files before running "Reload data" in Infinitewp? I can not say for sure, as the problem has been sporadic when running Infinitewp after upgrading to PHP 7.1.16 Further I have been looking at the changelog for PHP 7.1.16 and PHP 7.2.4, in PHP 7.1.6 changelog at http://www.php.net/ChangeLog-7.php#7.1.16 there is this: Opcache: Fixed bug #76074 (opcache corrupts variable in for-loop). However when looking at changelog for PHP 7.2.4, bug #76074 is not mentioned at all! I find that strange because at the page for bug #76074 it says "PHP Version: 7.2.3" So why was fix for bug #76074 not added in PHP 7.2.4? And was it a mistake that it was added to 7.1.16? Beacause that is the only bug fix for Opcache in PHP 7.1.16, I think it could be related to our users problems in PHP 7.2.16 as described above. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Tue Dec 03 17:01:29 2024 UTC |
I can reproduce this issue using the following test file: <?php class Foo { public $prop; } class Bar extends Foo {} and then running PHP twice as follows: $ sapi/cli/php -c php.ini -d opcache.file_cache=/tmp/opcache t171.php $ sapi/cli/php -c php.ini -d opcache.file_cache=/tmp/opcache -d opcache.file_cache_only=1 t171.php Yielding: php: /home/nikic/php-src/ext/opcache/zend_file_cache.c:1184: zend_file_cache_unserialize_prop_info: Assertion `((char*)(prop->name) < (char*)script->size)' failed. Aborted (core dumped) The important bit is that we run first with file_cache_only=0 (so interned strings are used) and then with file_cache_only=1 (so they aren't). This isn't quite your situation, but the root cause should be the same. The second bug report also has the assertion failure in the same place, so it's very likely that it's also the same issue.