Re: Re: file_cache is prone to some configuration changes

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