Bug #77312 [ReO]: accel_replace_string_by_process_permanent: Assertion `0' failed

Edit report at https://bugs.php.net/bug.php?id=77312&edit=1 ID: 77312 Updated by: nikic@php.net Reported by: sjon at hortensius dot net Summary: accel_replace_string_by_process_permanent: Assertion `0' failed Status: Re-Opened Type: Bug Package: opcache Operating System: archlinux PHP Version: 7.3.1 Block user comment: N Private report: N New Comment: Okay, so I guess the problem here is that fpm alters the ini entry, but does not restore the old value. Right now PHP_ADMIN_VALUE ends up calling fpm_php_zend_ini_alter_master which directly touches ini directives, while it probably should go through the normal zend_alter_ini_entry API, which will also register it in modified_ini_directives, so that it will be restored after the request. Previous Comments: ------------------------------------------------------------------------ [2019-01-15 13:12:48] sjon at hortensius dot net Thanks - I found in frame-1 that this is indeed an ini-setting - namely one that is pushed by nginx to fpm as PHP_ADMIN_VALUE (in our case upload_max_filesize) ------------------------------------------------------------------------ [2019-01-15 13:00:11] nikic@php.net https://github.com/php/php-src/blob/PHP-7.3.1/ext/opcache/ZendAccelerator.c#L689 Failing to replace value of an ini directive. In your core dump, can you please "f 2" and "p (char*)entry->key->val" and "p (char*)entry->value->val"? That should narrow down where this is happening. ------------------------------------------------------------------------ [2019-01-15 12:08:47] sjon at hortensius dot net Turns out FPM needed process.dumpable=true set as well to actually generate a coredump. Here is the backtrace after replacing the assert with a segfault: #0 accel_replace_string_by_process_permanent (str=0x56100556b3c0) at ext/opcache/ZendAccelerator.c:737 #1 0x00007f2c06511144 in accel_copy_permanent_strings (new_interned_string=0x7f2c06511431 <accel_replace_string_by_process_permanent>) at ext/opcache/ZendAccelerator.c:689 #2 0x00007f2c06511540 in accel_use_permanent_interned_strings () at ext/opcache/ZendAccelerator.c:765 #3 0x00005610031b7bff in zend_interned_strings_switch_storage (request=0 '\000') at Zend/zend_string.c:322 #4 0x00005610030e0d1f in php_module_shutdown () at main/main.c:2473 #5 0x0000561003268912 in main (argc=4, argv=0x7ffdd655b968) at sapi/fpm/fpm/fpm_main.c:2004 This happens pretty frequently ------------------------------------------------------------------------ [2019-01-11 09:03:04] sjon at hortensius dot net @lauri thanks for the hint - I already did that and was still unsuccessful. I'm happy to see if it still happens in 7.3.1 and reopen this bug if it does ------------------------------------------------------------------------ [2019-01-10 18:06:28] lauri dot kentta at gmail dot com @sjon, GDB detaches from forked processes by default. You can use "set follow-fork-mode child" or "set detach-on-fork off" to debug the php-fpm child processes. Also, just saying: since this bug was basically about a string not being found, it could have been the one I mentioned (which caused memory corruption and sometimes invalid string values). But no matter. ------------------------------------------------------------------------ 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=77312 -- Edit this bug report at https://bugs.php.net/bug.php?id=77312&edit=1