Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87268
Return-Path: <cmbecker69@gmx.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 82631 invoked from network); 24 Jul 2015 11:45:08 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 24 Jul 2015 11:45:08 -0000
Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
X-PHP-List-Original-Sender: cmbecker69@gmx.de
X-Host-Fingerprint: 212.227.15.19 mout.gmx.net  
Received: from [212.227.15.19] ([212.227.15.19:54551] helo=mout.gmx.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 7F/83-57278-14522B55 for <internals@lists.php.net>; Fri, 24 Jul 2015 07:45:07 -0400
Received: from [192.168.0.100] ([95.89.139.132]) by mail.gmx.com (mrgmx001)
 with ESMTPSA (Nemesis) id 0MEGIi-1Z7auA31Q0-00FX1I; Fri, 24 Jul 2015 13:44:58
 +0200
Message-ID: <55B22541.60708@gmx.de>
Date: Fri, 24 Jul 2015 13:45:05 +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: Adam Harvey <aharvey@php.net>
CC: PHP internals <internals@lists.php.net>
References: <55B0CADD.8000807@gmx.de> <CAEZPtU7aPzPQ=DL5fn9fOEuU_hySm5WXUkbjFw+Sq0T5xNfb3A@mail.gmail.com> <55B136BE.8010006@gmx.de> <CADajX4BC+wAWG4Cqo+dRMssWqVBKXo+wJJE+yq-Ox-oaQ_f73w@mail.gmail.com> <55B22174.1020704@gmx.de>
In-Reply-To: <55B22174.1020704@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Provags-ID:  V03:K0:oVCA90grICpSLxLyevME90vK1+mo9MwEJhMPL4NHQAi8oUjRv4m
 h4x6/mxwGZ6xrSZwwwparRDk44DtUNClahjbvY/WWx8jYS6/mNpsJQg3oyJ8TgHMMYOO38h
 mNMxqhSt7p/bncuDb8t5Yuau1vA+mSXUgoBmB1cdtyxGZRrXF6XYF4MUpA6xz7al7fN8UEv
 a2ltXjRNS4caby88Ql3gA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:sLsp/V9ozkI=:w1GuZtjcnnLuWnKQ1bLlVT
 GVm3jdHd5ebZnDhrjvV+r5QIo+Zf9koy74/4Aoeq0f7du3lTsiob0EzPgudw2kK/PB+d9yKaE
 QZz1popUz2EQustU6O3llktnfiWYUsoorYeBFFuJ+0dtCy/KUeCG5PZS8VxstYAvEOywWZn+W
 kkTnEg6Z8hLqwE9+G0VImbsL9HQq+mOw4wEBMzIsobhlgK7dh1Fedffmv6Hvlv/0SiTk/C/S4
 ww+HtpaMca1/dhxhBZxfpKoL4GNoZ4d0MbUXRvozDTP74DEAAqEtE9Hd5H2nK2vF+ROcDwj1T
 yuDTUGQxyk2s7FQd42+JOafBIQZ16h0CzNMwGqD50NQUg8DNQ9ypLZ6XXjUFv6U+Yrw7Sh6wY
 IeJx342etEoumwhtrCcqfVe/tIiAAIzEHxdfpl/ErMFoDmcv71Y8fely/LU3QJsziklbeW98O
 8xfxCTQCWTBbcD+OGwbg6K90PIn6h6+pDP7wEyWlIi9r8txVedfoPWEp0f8KmJ/eyFT1plXgn
 gevSBPY38wBpB83Rkpzz1os+Gg7MCgzMTB0Dx+mO5/YSpHiBGDrXVSPNhqwpaI0qPswl8QC5j
 1BXTap2lcPhkaMNJ3qSJ9/f2IrHXRe7iBmnVhGuCulGANRxww78tqmhjZlSsrfaArPXGp+hC2
 8lGaesLEiS/ppCiwLSCyt4eFKqz6wOQRVZajJcDqZ+sCDeyDytiwSHFP6gkil38B7e4k=
Subject: Re: [PHP-DEV] PCRE JIT stack size limit
From: cmbecker69@gmx.de (Christoph Becker)

Christoph Becker wrote:

> Adam Harvey wrote:
> 
>> On 23 July 2015 at 11:47, Christoph Becker <cmbecker69@gmx.de> wrote:
>> <snip great explanation, thanks>
>>> Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit).
>>>  That would mean, however, to add yet another ini setting, of which
>>> there are already so many.
>>
>> I'm not a big fan of that, although it's at least in the spirit of
>> what configuration settings are meant to be used for.
>>
>> What if we added the PCRE_ERROR_JIT_STACKLIMIT error constant to those
>> exposed to userland so that it's more easily noticed via
>> preg_last_error(), and adding a modifier that can be used to disable
>> the JIT on a per-pattern basis (by setting PCRE_NO_START_OPTIMIZE,
>> which admittedly disables other stuff too, but at least the regex will
>> run)? At least then users could check the error when the regex fails
>> and re-run the regex without the JIT if they chose to.
> 
> Yes, that would be an option.  I'm not sure if we need to touch
> PCRE_NO_START_OPTIMIZE (or if it would even help); simply not calling
> pcre_study() respectively not passing the studied extra data (second
> argument) to pcre_exec() should be sufficient.

Correction: we simply should not pass PCRE_STUDY_JIT_COMPILE to
pcre_study() if we want to disable JIT support for individual regexps.[1]

>> How likely is the average user to hit this, do you think?
> 
> I don't know.  The libpcre man pages say:
> 
> | JIT uses far less memory for recursion than the interpretive code,
> | and a maximum stack size of 512K to 1M should be more than enough for
> | any pattern.
> 
> Of course, a hard-coded 512K or even more would be rather much.  The
> default stack size (32K) for the regex in the test script of #70110
> would be sufficient, if the subject is repeated only about 2000 times,
> but that doesn't say much (the preg_match() is rather contrived).
> 
> Anyway, that shows that it's not only the pattern that's relevant for
> the needed JIT stack space, but also the subject string.

[1]
<https://github.com/php/php-src/blob/php-7.0.0beta2/ext/pcre/php_pcre.c#L436-L440>

-- 
Christoph M. Becker