On 24.11.2019 at 22:52, Dik Takken wrote:

> On 19-11-19 10:44, Christoph M. Becker wrote:
>
>> On 06.11.2019 at 14:02, Christoph M. Becker wrote:
>>
>>> while having had a closer look at <https://bugs.php.net/78754>, I
>>> learned that OPcache's file_cache is prone to some configuration
>>> changes, which may cause PHP segfaults (and maybe other malfunctions).
>>> For instance, if Xdebug is enabled while a file is compiled, but later
>>> disabled when executing that file, the process is segfaulting because
>>> the cached file relies on user opcode handlers which are no longer
>>> available without Xdebug loaded.  I'm presenting Xdebug as example
>>> because that likely caused the issues reported in that ticket, but
>>> basically any extension can call zend_set_user_opcode_handler() to
>>> install user opcode handlers, causing the same problems.
>>>
>>> It should be mentioned that, to my knowledge, shared memory caches are
>>> not affected by this (except for Windows), because re-attaching a
>>> differently configured php instance isn't possible at all.
>>>
>>> Anyhow, should we fix this (assuming a general fix would be possible),
>>> or would that be rather a documentation issue, based on the assumption
>>> that such configuration changes don't make sense in combination with
>>> OPcache at all (IOW, if such changes are done, users should reset OPcache)..
>>
>> Any thoughts regarding this issue?
>
> My knowledge of opcache is limited, so please forgive me if the
> following is incomplete or incorrect. My impression is that the amount
> of information that is used to compute the hash for the file cache
> directory is a bit low. I see the PHP version go in, an internal API
> version and some machine architecture related things.
>
> I would have expected that much - if not all - of the output of
> phpinfo() would be included in the hash for example. Better be safe than
> sorry. Would that be a sane thing to do? Are there any reasons why this
> is currently not done?


Factoring in the complete PHP info can't work, since that also contains
some request specific information.  Furthermore, a lot of these details
don't matter regarding the cache, so cache reuse might be suboptimal.

A more general problem is that OPcache calculates the system hash during
its startup, while other extensions may not even have been loaded.  Not
sure if that can be resolved.

--
Christoph M. Becker