Bug #76205 [Csd]: PHP-FPM sporadic crash when running Infinitewp

Edit report at https://bugs.php.net/bug.php?id=76205&edit=1 ID: 76205 Updated by: nikic@php.net Reported by: post at minhost dot no Summary: PHP-FPM sporadic crash when running Infinitewp Status: Closed Type: Bug Package: opcache Operating System: CentOS 7.4 PHP Version: 7.1.16 Assigned To: dmitry Block user comment: N Private report: N New Comment: Running tests with file cache I'm getting a segfault in Zend/tests/assert/expect_015.php while trying to access a string at address 0xa81. Looks like something didn't get unserialized there. Previous Comments: ------------------------------------------------------------------------ [2018-04-27 21:34:00] post at minhost dot no Thanks. Can I use this patch directly on PHP 7.1.17?: http://git.php.net/?p=php-src.git;a=patch;h=c6ce03e45e09087de8fc65f8a0a3345fea163ba2 ------------------------------------------------------------------------ [2018-04-27 21:28:11] dmitry@php.net Automatic comment on behalf of dmitry@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=c6ce03e45e09087de8fc65f8a0a3345fea163ba2 Log: Fixed bug #76205 (PHP-FPM sporadic crash when running Infinitewp). ------------------------------------------------------------------------ [2018-04-26 20:37:41] nikic@php.net 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. ------------------------------------------------------------------------ [2018-04-26 20:28:11] post at minhost dot no Thank you for looking into this! All I can say is that we have never yet seen it crash right after a php-fpm reload, so right after opcache is emptied, it does not seem to happen. Also the bactrace on the test server, when the crash happen on test server, opcache memory limit whas all used. However that does not make sence on produtction servers wich never reaches opcache memory limit. If my guess is right, you might be able to trigger the bug of you set opcache memory limit to for example 1 MB (or 0 if that is possible), and visit a WordPress site? But remember you need to have file cache as secondary fallback cache in place. Also, did you look at the bactrace on the similar bug report I created for Drupal?: https://bugs.php.net/bug.php?id=76258 - I was wondering if it seems to be the same bug or a different one? ------------------------------------------------------------------------ [2018-04-26 20:20:31] nikic@php.net The issue here is that the IS_UNSERIALIZED() macro checks for the pointer being either in script->mem or being an accel interned string. This does not account for the third possibility, where the string is in the arena allocated string memory region (when unserializing into non-shm). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76205 -- Edit this bug report at https://bugs.php.net/bug.php?id=76205&edit=1