Bug #71261 [Com]: Wrong bytecode in cache of array index named 'init' containing 0 indexed subarr

Edit report at https://bugs.php.net/bug.php?id=71261&edit=1 ID: 71261 Comment by: nikic@php.net 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: 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? Previous Comments: ------------------------------------------------------------------------ [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