On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
> <johan...@schlueters.de> wrote:
> 
> > There were mysqli threading bugs, the last one of those actually had
> > been engine bugs which affected other extensions, too. See i.e.
> > http://news.php.net/php.internals/59353
> >
> > Such bugs identified a year after the release of 5.4 gives me quite a
> > good indication of the little actual testing being done overall.
> 
> Can you stay fair, check your backlog and the verbose mail exchanges
> we had with the mysql connectivity team about these issues? Before and
> after the bugs were reported? thanks.

I said "There were mysqli threading bugs" and yes, it took some time to
fix those. But to be fair it also has to be mentioned that not all bugs
pushed to "yet another mysqli threading bug" had actually been mysqli
issues.


Out of curiosity I had a quick test: Running wordpress with a bunch of
parallel threads. Immediately found some minor threading issues of this
form:

        ==19088== Possible data race during read of size 1 at 0x4c82820 by 
thread #6
        ==19088==    at 0x47747D: pcre_get_compiled_regex_cache (php_pcre.c:387)
        ==19088==    by 0x4777CB: php_pcre_replace (php_pcre.c:986)
        ==19088==    by 0x47794E: php_replace_in_subject (php_pcre.c:1311)
        ==19088==    by 0x478022: preg_replace_impl (php_pcre.c:1409)
        ==19088==    by 0x478377: zif_preg_replace (php_pcre.c:1429)
        ==19088==    by 0x76EC36: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:546)
        ==19088==    by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
        ==19088==    by 0x6E38D2: zend_execute_scripts (zend.c:1316)
        ==19088==    by 0x67C180: php_execute_script (main.c:2479)
        ==19088==    by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
        ==19088==    by 0x79E299: php_thread (main.c:63)
        ==19088==    by 0x4A0C01D: mythread_wrapper (hg_intercepts.c:221)
        ==19088==  Address 0x4c82820 is 0 bytes inside a block of size 11 
alloc'd
        ==19088==    at 0x4A0626E: malloc (vg_replace_malloc.c:236)
        ==19088==    by 0x339F280871: strdup (in /lib64/libc-2.12.so)
        ==19088==    by 0x339F228FE3: setlocale (in /lib64/libc-2.12.so)
        ==19088==    by 0x449074: seek_to_tz_position (parse_tz.c:283)
        ==19088==    by 0x4490B6: timelib_timezone_id_is_valid (parse_tz.c:312)
        ==19088==    by 0x422231: zif_date_default_timezone_set 
(php_date.c:4350)
        ==19088==    by 0x76EC36: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:546)
        ==19088==    by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
        ==19088==    by 0x6E38D2: zend_execute_scripts (zend.c:1316)
        ==19088==    by 0x67C180: php_execute_script (main.c:2479)
        ==19088==    by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
        ==19088==    by 0x79E299: php_thread (main.c:63)
        ==19088== 
        ==19088== Possible data race during read of size 1 at 0x4c82820 by 
thread #3
        ==19088==    at 0x4A07823: strcmp (hg_intercepts.c:2342)
        ==19088==    by 0x4772D7: pcre_get_compiled_regex_cache (php_pcre.c:264)
        ==19088==    by 0x4777CB: php_pcre_replace (php_pcre.c:986)
        ==19088==    by 0x47794E: php_replace_in_subject (php_pcre.c:1311)
        ==19088==    by 0x478022: preg_replace_impl (php_pcre.c:1409)
        ==19088==    by 0x478377: zif_preg_replace (php_pcre.c:1429)
        ==19088==    by 0x76EC36: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:546)
        ==19088==    by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
        ==19088==    by 0x6E38D2: zend_execute_scripts (zend.c:1316)
        ==19088==    by 0x67C180: php_execute_script (main.c:2479)
        ==19088==    by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
        ==19088==    by 0x79E299: php_thread (main.c:63)
        ==19088==  Address 0x4c82820 is 0 bytes inside a block of size 11 
alloc'd
        ==19088==    at 0x4A0626E: malloc (vg_replace_malloc.c:236)
        ==19088==    by 0x339F280871: strdup (in /lib64/libc-2.12.so)
        ==19088==    by 0x339F228FE3: setlocale (in /lib64/libc-2.12.so)
        ==19088==    by 0x449074: seek_to_tz_position (parse_tz.c:283)
        ==19088==    by 0x4490B6: timelib_timezone_id_is_valid (parse_tz.c:312)
        ==19088==    by 0x422231: zif_date_default_timezone_set 
(php_date.c:4350)
        ==19088==    by 0x76EC36: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:546)
        ==19088==    by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
        ==19088==    by 0x6E38D2: zend_execute_scripts (zend.c:1316)
        ==19088==    by 0x67C180: php_execute_script (main.c:2479)
        ==19088==    by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
        ==19088==    by 0x79E299: php_thread (main.c:63)

So at least on my Linux box there is an issue around the usage of
setlocale(). Gues this won't show on Windows as Windows locale handling
is different, but again a data point showing that most developers don't
spend attention on these things. (and well, handlin locales in a
threaded environment is tough ... as different scripts might use
different locales, similar to the CWD things ....)

johannes
> --
> Pierre
> 
> @pierrejoye
> 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to