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

From: Date: Sat, 09 Jan 2016 10:20:32 +0000
Subject: Bug #71261 [Asn]: Wrong bytecode in cache of array index named 'init' containing 0 indexed subarr
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-198542@lists.php.net to get a copy of this message
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:             Assigned
 Type:               Bug
 Package:            opcache
 Operating System:   Linux
-PHP Version:        7.0.1
+PHP Version:        7.0.2
 Assigned To:        laruence
 Block user comment: N
 Private report:     N

 New Comment:

Still the same with PHP 7.0.2


Previous Comments:
------------------------------------------------------------------------
[2016-01-05 05:43:07] laruence@php.net

the problem probably be a array which is cached in opcache is altered in pdo_set_attribute. 

anyway, I committed a fix here: https://github.com/php/php-src/commit/36b4311edd3e2dec31de1582c207e83b09d6f42b

maybe you could try with the latest snapshot ..

------------------------------------------------------------------------
[2016-01-03 22:25:55] 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-02 16:43:51] laruence@php.net

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;
 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(&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:25:38] jo at feuersee dot de

jo@l33t ~/tmp> valgrind php -S localhost:8080 -t
/srv/www/vhosts/www.feuersee.de/groupware/htdocs/
==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/www.feuersee.de/groupware/htdocs/
==20223==
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/www.feuersee.de/groupware/htdocs
Press Ctrl-C to quit.
==20223==
==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/pdo_mysql.so)
==20223==    by 0x109B43E9: pdo_dbh_attribute_set (in /usr/lib64/php7/extensions/pdo.so)
==20223==    by 0x109B2656: zim_PDO_dbh_constructor (in /usr/lib64/php7/extensions/pdo.so)
==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/vgpreload_memcheck-amd64-linux.so)
==20223==    by 0x64AEB5B: __libc_freeres (in /lib64/libc-2.19.so)
==20223==    by 0x4A2370C: _vgnU_freeres (in /usr/lib64/valgrind/vgpreload_core-amd64-linux.so)
==20223==    by 0x2F: ???
==20223==    by 0x10BCE357: pdo_mysql_set_attribute (in /usr/lib64/php7/extensions/pdo_mysql.so)
==20223==    by 0x109B43E9: pdo_dbh_attribute_set (in /usr/lib64/php7/extensions/pdo.so)
==20223==    by 0x109B2656: zim_PDO_dbh_constructor (in /usr/lib64/php7/extensions/pdo.so)
==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==
==20223==
==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==
==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==
==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:17:59] 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...

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=71261


--
Edit this bug report at https://bugs.php.net/bug.php?id=71261&edit=1


Thread (17 messages)

« previous php.bugs (#198542) next »