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

From: Date: Wed, 16 Jan 2019 13:10:26 +0000
Subject: Bug #77312 [Com]: accel_replace_string_by_process_permanent: Assertion `0' failed
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-218992@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77312&edit=1

 ID:                 77312
 Comment by:         sjon at hortensius dot net
 Reported by:        sjon at hortensius dot net
 Summary:            accel_replace_string_by_process_permanent: Assertion
                     `0' failed
 Status:             Assigned
 Type:               Bug
 Package:            FPM related
 Operating System:   archlinux
 PHP Version:        7.3.1
 Assigned To:        bukka
 Block user comment: N
 Private report:     N

 New Comment:

thanks, I've tried your patch (combined with the patch posted in #77430 ) but I did see another
segfault with a similar backtrace - this time not for an entry set by nginx through fastcgi, but a
setting that's directly configured in the php-fpm pool configuration through php_admin_value. 

That seems to go through this code: https://github.com/php/php-src/blob/1ad08256f349fa513157437abc4feb245cce03fc/sapi/fpm/fpm/fpm_php.c#L127
maybe that requires the same fix ?


Previous Comments:
------------------------------------------------------------------------
[2019-01-16 09:07:08] mnikulin at plesk dot com

The bug can be reproduced by accessing any php file even just

    <?php echo 10; ?>

Certainly, OpCache must be enabled in php.ini

    zend_extension=opcache.so
    opcache.enable=1

It happens during child exit, so simple way to reproduce
is to set short timeout for on-demand manager in a pool .conf file

    pm = ondemand
    pm.process_idle_timeout = 2s
    catch_workers_output = yes
    php_value[error_reporting] = 22519

Unsure which bits of error_reporting should be set.

The pool name in log messages after "child 9958 said into stderr" may be truncated.

------------------------------------------------------------------------
[2019-01-15 14:13:31] nikic@php.net

This might do it: https://gist.github.com/nikic/c4c4ac241da02af410ce4f720c31d628

But fpm is really not my area... Maybe bukka could take a look?

------------------------------------------------------------------------
[2019-01-15 13:54:21] nikic@php.net

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.

------------------------------------------------------------------------
[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.

------------------------------------------------------------------------


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


Thread (26 messages)

« previous php.bugs (#218992) next »