Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107859
To: Dik Takken <d.takken@xs4all.nl>, PHP internals <internals@lists.php.net>
References: <f61573e3-a3db-a266-153f-70b87802291f@gmx.de>
 <6fbd8905-a415-c723-dc87-ba7209539c0c@gmx.de>
 <261a9e80-8b88-2147-7a23-128621795f39@xs4all.nl>
Message-ID: <e22870c2-a9f8-ecd8-de60-c0828604f09c@gmx.de>
Date: Tue, 26 Nov 2019 09:24:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <261a9e80-8b88-2147-7a23-128621795f39@xs4all.nl>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: file_cache is prone to some configuration changes
From: 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 OPca=
che)..
>>
>> 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.

=2D-
Christoph M. Becker