file_cache is prone to some configuration changes

  107773
November 6, 2019 13:02 cmbecker69@gmx.de ("Christoph M. Becker")
Hi internals,

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

--
Christoph M. Becker
  107825
November 19, 2019 09:44 cmbecker69@gmx.de ("Christoph M. Becker")
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? -- Christoph M. Becker
  107855
November 24, 2019 21:52 d.takken@xs4all.nl (Dik Takken)
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? >
Hi, 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? Thanks, Dik Takken
  107859
November 26, 2019 08:24 cmbecker69@gmx.de ("Christoph M. Becker")
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