Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87307 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29453 invoked from network); 26 Jul 2015 22:06:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2015 22:06:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.17.20 mout.gmx.net Received: from [212.227.17.20] ([212.227.17.20:54691] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/93-06606-9C955B55 for ; Sun, 26 Jul 2015 18:06:07 -0400 Received: from [192.168.0.100] ([95.89.139.132]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M0yaB-1Z3KBO2Th1-00v5lo; Mon, 27 Jul 2015 00:05:57 +0200 Message-ID: <55B559C7.9060304@gmx.de> Date: Mon, 27 Jul 2015 00:05:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anatol Belski , 'Pierre Joye' CC: 'PHP internals' References: <55B0CADD.8000807@gmx.de> <55B136BE.8010006@gmx.de> <046401d0c644$9cf76880$d6e63980$@belski.net> <55B2B78A.4080202@gmx.de> <048001d0c665$ed19ec40$c74dc4c0$@belski.net> <55B2D779.9090409@gmx.de> <04d301d0c6e5$6b28f0c0$417ad240$@belski.net> <55B3B2E6.7080905@gmx.de> <056e01d0c7d9$b1edd990$15c98cb0$@belski.net> In-Reply-To: <056e01d0c7d9$b1edd990$15c98cb0$@belski.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:evYb9k2a0Z+loAvdk3p5MAfECxSWL9UN6Mju/T59lyCHgg+rnGF Vpnn2Bd7PVs1JKOL9ar9MGaiFYDlwFN9yRC8ySwu5HZpToCx5IsCavbKPw1rrKX0tUUk1K4 7gWIZTf1EUtN5zpviUOsUhTJekqPmUUK0fYwmRkFb0UDLSaHT4PulIMRCr4b5XhzBSRy0Hp eiGqiYUpkADdTiUU/jGWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Flu94kab7xc=:VcF0bu/sEEnQBmPs6akhbr 8fUf1trbG0BTY2zVtt9cCU7Z1b2kW4n4KGpjz0DDFAv430dAqU1ypSGMeVtlcq6czQur2ZfaE IxTOJqZT5Nuzc3+GuNsonqDlcOmqawSY1bbovore09YKRyZNrXSFR8Hn0fWZ4ArtUoN2t/P9m c8CB2Is4ood98KLkqi01YkGgQBzGoPuRTNtWB+hlih4rkUC7oBRWADuXPsJm3JfEySmzyTuez kCe4qQtPByY1HPBD9FuOkB3tCVVlZoUTVrX9NbVO7GJS27HJAI9tgNYTuYlWuRwvfMcs7cNup E3760egyqzO3U/VPUJ3m7UeinIbDsPRFEJ0hYRFAh8/iKBXBN9P3tDVenR3uZk6w6qoqkOqZb TwBWWCdHjP6zbkW1E5ljjMniWmkb+7GZpoUbAHepG4vHN5jp5xe3ZAdeT/qE94HljQVmwJSov fn3flRWVSKt2D8KPphtEHWmR0R+M1k67Fp3v7q01r74VuF+ol1F/yNcnMHojXM6qGqxeoYmD+ 0dOE3WdZ8H0HZzuvOmnsQOjuC1YtpyNjAhnsd+PZ3wuYF9dbyXXn/TDdd6fq3WRHpcrPAxXJ6 7VI1DfwZBlBmByA5ALIiY1THu+mVS5UOHbXYSVUETpMT2TCZwOknBZL5C1dbUrG0SxlJ05JBv A7rgK9Y95/prP5dj+wK4gmvRHz8XI97jd3OZ3M22ZSxztIO+HPqgrHCCZ6PT1xw5vr68= Subject: Re: [PHP-DEV] PCRE JIT stack size limit From: cmbecker69@gmx.de (Christoph Becker) Hi Anatol, Anatol Belski wrote: > Hi Christoph, > >> -----Original Message----- >> From: Christoph Becker [mailto:cmbecker69@gmx.de] >> Sent: Saturday, July 25, 2015 6:02 PM >> To: Anatol Belski ; 'Pierre Joye' >> >> Cc: 'PHP internals' >> Subject: Re: [PHP-DEV] PCRE JIT stack size limit >> >> Hi Anatol, >> >> Anatol Belski wrote: >> >>>> -----Original Message----- >>>> From: Christoph Becker [mailto:cmbecker69@gmx.de] >>>> Sent: Saturday, July 25, 2015 2:25 AM >>>> To: Anatol Belski ; 'Pierre Joye' >>>> >>>> Cc: 'PHP internals' >>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit >>>> >>>> I would not suggest to change the return value of preg_match() and friends. >>>> FALSE seems to be appropriate here. Instead I suggest to add a new >>>> error constant which would be returned from preg_last_error(). >>>> >>> Yep, sounds feasible. At least users can be informed about this kind of error, >> seems a constant is feasible for 7.0. >> >> That would be nice. I'll make a respective PR. > Thanks. > >> >>> Btw I've just noticed that the snippet I've posted earlier won't currently work. >>> >>> If (false === preg_match(",evil pattern,", ...)) { >>> If (OUT_OF_JIT_STACK == pcre_last_error()) { >>> ini_set("pcre.jit", 0); >>> // retry >>> } >>> } >>> >>> The retry would fail even when JIT is disabled on demand. This is >>> actually rather unexpected, maybe something in PCRE JIT state cannot >>> be recovered once JIT compilation has failed. But actually, even >>> without running into debugging, it is also a bad sign telling that the >>> behavior can get complicated ( >> >> Indeed! That's caused by our PCRE cache. The cached regex is alread studied >> with JIT info, as all that happens in pcre_get_compiled-regex_cache[1]. So >> switching pcre.jit at runtime may not have the desired effect. I'm not sure if that >> has to be regarded as bug, and whether we should do something about it. One >> solution might be to clear the regex cache whenever the ini setting changes. I'll >> have a closer look. >> > Good catch. Maybe another option could be implementing the PHP pattern above > In C. Say > > - check what pcre_exec delivered > - if it’s the JIT stack error - look for the pattern in the cache > - if it's found - remove it from the cache > - recompile and cache > - exec a non JIT pattern version > > However this would silently ignore JIT, not transparent for user. Maybe another > option could be introducing a user space function to clear a particular pattern from > the cache. When expunging the full cache, it'll for sure have a negative performance > effect when the cache isn't empty. But it's actually logic as one can base it on the idea - > either JIT is enabled for everything, or it is not (for everything). Definitely interesting ideas. However, currently I'm leaning towards a full-fledged solution in PHP 7.1 (whatever that may be), and to only add the error constant for PHP 7.0. Users can set pcre.jit=0 in php.ini and not change the setting during runtime, if necessary. FWIW, some hours ago I've implemented the clean whole cache solution: . >>> Running for the INI option and some custom JIT stack functionality needs >> more brainstorming and test. Please ping when you have an initial >> implementation, I'd be glad to help testing, etc. anyway. >> >> All in all it seems that we probably should have an RFC for that. I'll consider to >> write one, but there's no need to hurry – too late for 7.0 anyway. :) >> > Yep, the whole needs a good consideration about how to do it best without a big > impact on the user side. Also probably it could be worth it to check how PCRE2 > behaves in this cases, maybe it were worthwhile to upgrade to PCRE2 for 7.1. Indeed, offering support for PCRE2 should be considered for 7.1. And also support of the JIT fast path API: . Regards -- Christoph M. Becker