|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2016-01-01 17:48 UTC] 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
)
)
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sun Dec 22 06:01:30 2024 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: https://bugs.php.net/bugs-generating-backtrace.phpcould 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; options: 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) { continue; } - pdo_dbh_attribute_set(dbh, long_key, attr_value); + ZVAL_COPY(©, attr_value); + pdo_dbh_attribute_set(dbh, long_key, ©); + zval_ptr_dtor(©); } ZEND_HASH_FOREACH_END(); } I will do a better fix if it works