|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #71261 Wrong bytecode in cache of array index named 'init' containing 0 indexed subarr
Submitted: 2016-01-01 17:48 UTC Modified: 2016-04-12 19:23 UTC
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: jo at feuersee dot de Assigned: laruence (profile)
Status: Closed Package: opcache
PHP Version: 7.0.2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
45 - 35 = ?
Subscribe to this entry?

 [2016-01-01 17:48 UTC] jo at feuersee dot de
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:
$conf['init'] = array(
  "SET NAMES'utf8'",
return $conf;

$conf = require 'config.php';

Expected result:
    [init] => Array
            [0] => SET NAMES 'utf8'
            [1] => SHOW TABLES


Actual result:
    [init] => Array
            [0] => 1
            [1] => SHOW TABLES



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-01-01 17:54 UTC]
Could you check if the problem goes away if you run with opcache.optimization_level=0?
 [2016-01-01 18:03 UTC] 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 18:11 UTC]
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 19:35 UTC] jo at feuersee dot de
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?
 [2016-01-01 19:56 UTC]
If your code is runnable using CLI, the easiest way to get a backtrace is through valgrind. Just run

    valgrind php ...args...

Alternatively, using gdb run "gdb --args php ...args..." and then "r" followed by "bt" in the gdb prompt.

If it doesn't run through cli it's probably easiest to get the backtrace from a core file, we have some info on that here:
 [2016-01-01 21:00 UTC] jo at feuersee dot de
THX. Unfortunately, the used binaries for openSUSE Leap 42.1 (from have debug mode disabled. 

I'll check over the WE wether installing PHP7 from source is less painful than changing the app to work in CLI context.
 [2016-01-02 05:03 UTC]
-Assigned To: +Assigned To: laruence
 [2016-01-02 05:03 UTC]
you can also try to make it coredump with "opcache.protect_memory=1 ", and paste the backtrace here. thanks
 [2016-01-02 05:03 UTC]
-Status: Assigned +Status: Feedback
 [2016-01-02 16:17 UTC] jo at feuersee dot de
-Status: Feedback +Status: Assigned
 [2016-01-02 16:17 UTC] jo at feuersee dot de
Would it be useful to provide a trace of PHP running with built-in webserver?

Running the script via CLI doesn't looks useful as I can't reproduce the bug there (the opcache is invalid after execution, thus always regenerated). And Apache2 doesn't core dump at all, can't see the problem why. This isn't my kind of cake...
 [2016-01-02 16:25 UTC] jo at feuersee dot de
jo@l33t ~/tmp> valgrind php -S localhost:8080 -t /srv/www/vhosts/
==20223== Memcheck, a memory error detector
==20223== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20223== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20223== Command: php -S localhost:8080 -t /srv/www/vhosts/
PHP 7.0.1 Development Server started at Sat Jan  2 17:21:50 2016
Listening on http://localhost:8080
Document root is /srv/www/vhosts/
Press Ctrl-C to quit.
==20223== Process terminating with default action of signal 11 (SIGSEGV)
==20223==  Bad permissions for mapped region at address 0x16951778
==20223==    at 0x479C85: convert_to_boolean (in /usr/bin/php)
==20223==    by 0x10BCE357: pdo_mysql_set_attribute (in /usr/lib64/php7/extensions/
==20223==    by 0x109B43E9: pdo_dbh_attribute_set (in /usr/lib64/php7/extensions/
==20223==    by 0x109B2656: zim_PDO_dbh_constructor (in /usr/lib64/php7/extensions/
==20223==    by 0x51E9F1: ZEND_DO_FCALL_SPEC_HANDLER (in /usr/bin/php)
==20223==    by 0x51A851: execute_ex (in /usr/bin/php)
==20223==    by 0x51B1C5: zend_execute (in /usr/bin/php)
==20223==    by 0x48EC4C: zend_execute_scripts (in /usr/bin/php)
==20223==    by 0x3E208C: php_execute_script (in /usr/bin/php)
==20223==    by 0x5FDC21: php_cli_server_dispatch_script (in /usr/bin/php)
==20223==    by 0x5FEEF6: php_cli_server_dispatch (in /usr/bin/php)
==20223==    by 0x5FF81A: php_cli_server_recv_event_read_request (in /usr/bin/php)
==20223== Invalid free() / delete / delete[] / realloc()
==20223==    at 0x4C2A37C: free (in /usr/lib64/valgrind/
==20223==    by 0x64AEB5B: __libc_freeres (in /lib64/
==20223==    by 0x4A2370C: _vgnU_freeres (in /usr/lib64/valgrind/
==20223==    by 0x2F: ???
==20223==    by 0x10BCE357: pdo_mysql_set_attribute (in /usr/lib64/php7/extensions/
==20223==    by 0x109B43E9: pdo_dbh_attribute_set (in /usr/lib64/php7/extensions/
==20223==    by 0x109B2656: zim_PDO_dbh_constructor (in /usr/lib64/php7/extensions/
==20223==    by 0x51E9F1: ZEND_DO_FCALL_SPEC_HANDLER (in /usr/bin/php)
==20223==    by 0x51A851: execute_ex (in /usr/bin/php)
==20223==    by 0x51B1C5: zend_execute (in /usr/bin/php)
==20223==    by 0x48EC4C: zend_execute_scripts (in /usr/bin/php)
==20223==    by 0x3E208C: php_execute_script (in /usr/bin/php)
==20223==  Address 0x67072d0 is 0 bytes inside data symbol "noai6ai_cached"
==20223== HEAP SUMMARY:
==20223==     in use at exit: 2,922,691 bytes in 27,842 blocks
==20223==   total heap usage: 35,880 allocs, 8,039 frees, 5,101,975 bytes allocated
==20223== LEAK SUMMARY:
==20223==    definitely lost: 0 bytes in 0 blocks
==20223==    indirectly lost: 0 bytes in 0 blocks
==20223==      possibly lost: 2,036,653 bytes in 21,653 blocks
==20223==    still reachable: 886,038 bytes in 6,189 blocks
==20223==         suppressed: 0 bytes in 0 blocks
==20223== Rerun with --leak-check=full to see details of leaked memory
==20223== For counts of detected and suppressed errors, rerun with: -v
==20223== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
 [2016-01-02 16:43 UTC]
could you please try with this quick fix?
diff --git a/ext/pdo/pdo_dbh.c b/ext/pdo/pdo_dbh.c
index cda07fb..a0b310e 100644
--- a/ext/pdo/pdo_dbh.c
+++ b/ext/pdo/pdo_dbh.c
@@ -374,7 +374,7 @@ static PHP_METHOD(PDO, dbh_constructor)
                dbh->driver = driver;
                if (options) {
-                   zval *attr_value;
+                 zval copy, *attr_value;
                        zend_ulong long_key;
                        zend_string *str_key = NULL;

@@ -382,7 +382,9 @@ options:
                                if (str_key) {
-                           pdo_dbh_attribute_set(dbh, long_key, attr_value);
+                         ZVAL_COPY(&copy, attr_value);
+                         pdo_dbh_attribute_set(dbh, long_key, &copy);
+                         zval_ptr_dtor(&copy);
                        } ZEND_HASH_FOREACH_END();

I will do a better fix if it works
 [2016-01-02 16:44 UTC]
-Status: Assigned +Status: Feedback
 [2016-01-03 22:25 UTC] jo at feuersee dot de
-Status: Feedback +Status: Assigned
 [2016-01-03 22:25 UTC] jo at feuersee dot de
I could try to test the patch, but I have to admit that compiling PHP from sources ist't an my daily schedule for at lest the last 10 yrs. This would take some time.

On the other hand, AFAICS we are talking about a patch of PDO. I really don't think this bug is PDO related, it is opcache. The result is - in my app - that the valid SQL query "SET NAMES 'utf8'" gets evaluated to "1" which isn't a valid SQL statement at all.

I thought that someone who does maintain the opcode cache could look up the 'init' string and/or related code and goes "yeah, we really screwed this up" and fix it.

OK, if it's not this way I'll try the hard way.

Happy new year everyone, besides ;)
 [2016-01-05 05:43 UTC]
the problem probably be a array which is cached in opcache is altered in pdo_set_attribute. 

anyway, I committed a fix here:

maybe you could try with the latest snapshot ..
 [2016-01-09 10:20 UTC] jo at feuersee dot de
-PHP Version: 7.0.1 +PHP Version: 7.0.2
 [2016-01-09 10:20 UTC] jo at feuersee dot de
Still the same with PHP 7.0.2
 [2016-04-12 19:23 UTC] jo at feuersee dot de
-Status: Assigned +Status: Closed
 [2016-04-12 19:23 UTC] jo at feuersee dot de
Can't reproduce with PHP 7.0.5
Did noch check PHP 7.0.3 or .4
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon May 20 01:01:32 2024 UTC