Edit report at https://bugs.php.net/bug.php?id=77312&edit=1
ID: 77312
Updated by: dmitry@php.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:
This should fix the problem.
https://github.com/php/php-src/commit/bfadd9fdaf46dd9d9d447de38820122383af9c71
Please, verify and close the bug.
Previous Comments:
------------------------------------------------------------------------
[2019-02-03 19:47:14] bukka@php.net
I started playing with that and used zend_alter_ini_entry_ex. Just replacement will not work
correctly as discussed because it returns the original value. However if it was moved and done
before each request then it might work. Just need to find a clean way how to get the worker pool in
main request init - basically come up with some clean implementation. Will try again next week so
assigned it back to myself as it looks that Dmitry is busy anyway.
------------------------------------------------------------------------
[2019-01-27 16:49:47] bukka@php.net
I don't have much time to look what Opcache exactly does so re-assigning to Dmitry as he might
have a better idea what to do and what's the best approach.
I can just comment on the FPM behaviour and requirements. Basically the ini values are set in the
following cases:
* if php_value or php_admin_value is set in the FPM config, then the ini is modified on child init
(it means when the process is created and ready to handle requests - it means it can handle multiple
requests and should be the for the whole child life)
* if FCGI request sets PHP_VALUE or PHP_ADMIN_VALUE envs, then it is modified as well (from the code
it looks that this should actually stay set for all other requests in the child even if the
PHP_VALUE or PHP_ADMIN_VALUE are no longer set).
So it means that FPM needs a way to set an ini in the process that won't get changed. I'm
thinking that it might make sense to either save it as an original or maybe create another field for
the permanently modified ini values. Not really sure though.
------------------------------------------------------------------------
[2019-01-24 14:26:39] bukka@php.net
Ok I guess it will probably need a longer look then :)
------------------------------------------------------------------------
[2019-01-24 14:09:22] nikic@php.net
I'm no longer sure if using zend_alter_ini_entry is right in this context, I think it may break
the ini_restore() functionality. (Which should probably restore to the ini value specified through
php_value).
------------------------------------------------------------------------
[2019-01-24 14:03:23] bukka@php.net
From a quick look I agree that we should use zend_alter_ini_entry_ex instead. However I would use it
in fpm_php_apply_defines_ex and call it instead of fpm_php_zend_ini_alter_master which could be then
dropped. That would also keep extension and disable_{functions,classes} working.
------------------------------------------------------------------------
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