Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107825
To: PHP internals <internals@lists.php.net>
References: <f61573e3-a3db-a266-153f-70b87802291f@gmx.de>
Message-ID: <6fbd8905-a415-c723-dc87-ba7209539c0c@gmx.de>
Date: Tue, 19 Nov 2019 10:44:00 +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: <f61573e3-a3db-a266-153f-70b87802291f@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: file_cache is prone to some configuration changes
From: 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 OPcach=
e)..

Any thoughts regarding this issue?

=2D-
Christoph M. Becker