Edit report at https://bugs.php.net/bug.php?id=71261&edit=1
ID: 71261
User updated by: jo at feuersee dot de
Reported by: jo at feuersee dot de
Summary: Wrong bytecode in cache of array index named 'init'
containing 0 indexed subarr
Status: Open
Type: Bug
Package: opcache
Operating System: Linux
PHP Version: 7.0.1
Block user comment: N
Private report: N
New Comment:
Yep, it crashes with opcache.protect_memory=1 "child pid 2844 exit signal Segmentation
fault"
Unfortunately, xdebug fails to start due to API version 320151012.
Is there another convenient way to provide a backtrace?
Previous Comments:
------------------------------------------------------------------------
[2016-01-01 18:11:52] nikic@php.net
Thanks, so the optimizer is not the culprit. Can you do a run with opcache.protect_memory=1 and see
if it crashes (segfault or some such)? And if so, get a backtrace?
------------------------------------------------------------------------
[2016-01-01 18:03:55] jo at feuersee dot de
All opcache related ini settings were at default.
Changing opcache.optimization_level=0 did not help, the problem still occurs.
------------------------------------------------------------------------
[2016-01-01 17:54:50] nikic@php.net
Could you check if the problem goes away if you run with opcache.optimization_level=0?
------------------------------------------------------------------------
[2016-01-01 17:48:08] jo at feuersee dot de
Description:
------------
Let me first say that the test script below actually fails to reproduce the bug. I tried the whole
day to provide a simple way to reproduce the problem, but without success.
But what happens is pretty much the execution of caller.php:
Another file is parsed via require() and assigned to a PHP variable. The problem is that the array
index named 'init' seems to be incorrectly cached, it is still an array, but index 0
always becomes 1.
Other (scalar) entries in $conf are not affected. To add some oddness:
- Only the array index called 'init' is affected. Even 'Init' does work, so
it's pretty unlikely to happen.
- Only the subindex 0 is affected. Thus, a simple workaround this bug is to force the array keys to
start with eg. 1
- When forcing the 1st entry to have the array key of -1, the 2nd array key (becoming the key 0
then) is affected.
The application where the bug occurs is way more complex involving ~30 files, autoloader and all the
bells and whistles. I am, on the other side, sure that it's not an application bug, but a PHP
issue.
That is because:
1) The application did and does work fine with older PHP versions until 5.6.15 (incl). Did not test
with PHP7.0.0
2) The problem does not occur when Zend opcache is disabled
3) After altering and saving config.php (thus forcing the opcache to expire), the next execution
will be perfectly fine. The next ones will always fail, until the cache is invalidated again
4) I nailed this behavior down by adding the print_r call directly next to the require call (just as
in the test script), so there is no way the app is responsible (by altering the value of
'init' keys itself.
As mentioned, AFAICS it only occurs on array keys named 'init', so it's unlikely to
happen. If it happends, the impact is sadly grave.
Test script:
---------------
config.php:
<?php
$conf['init'] = array(
"SET NAMES'utf8'",
"SHOW TABLES"
);
return $conf;
--eof
caller.php:
<?php
$conf = require 'config.php';
print_r($conf);
--eof
Expected result:
----------------
Array
(
[init] => Array
(
[0] => SET NAMES 'utf8'
[1] => SHOW TABLES
)
)
Actual result:
--------------
Array
(
[init] => Array
(
[0] => 1
[1] => SHOW TABLES
)
)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=71261&edit=1