Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65433 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50414 invoked from network); 29 Jan 2013 20:42:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jan 2013 20:42:26 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:64948] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 23/CC-10721-13438015 for ; Tue, 29 Jan 2013 15:42:25 -0500 Received: from [192.168.2.20] (ppp-93-104-29-211.dynamic.mnet-online.de [93.104.29.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id C186665557; Tue, 29 Jan 2013 21:42:21 +0100 (CET) To: Pierre Joye Cc: Zeev Suraski , PHP internals In-Reply-To: References: <1359459921.3916.105.camel@guybrush> <1359460880.3916.136.camel@guybrush> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 Jan 2013 21:43:17 +0100 Message-ID: <1359492198.3916.1217.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] ZTS - why are you using it? From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote: > On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter > 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 >