Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87266
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
Message-ID: <55B21EF8.1050605@gmx.de>
Date: Fri, 24 Jul 2015 13:18:16 +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: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <55B0CADD.8000807@gmx.de>	<CAEZPtU7aPzPQ=DL5fn9fOEuU_hySm5WXUkbjFw+Sq0T5xNfb3A@mail.gmail.com>	<55B136BE.8010006@gmx.de> <CAEZPtU6ofjJsueh+f-uyCo1Cci6pfiMGjHVnAODxLizqVOwtnw@mail.gmail.com>
In-Reply-To: <CAEZPtU6ofjJsueh+f-uyCo1Cci6pfiMGjHVnAODxLizqVOwtnw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PCRE JIT stack size limit
From: cmbecker69@gmx.de (Christoph Becker)

Pierre Joye wrote:

> On Jul 23, 2015 9:47 PM, "Christoph Becker" <cmbecker69@gmx.de> wrote:
>>
>> Ah, I should have explained better that libpcre's JIT support is
>> implemented as own virtual machine, and libpcre has functions to use a
>> custom stack which is allocated on the heap.  If these functions are not
>> used (as it's now in ext/pcre) a fixed 32K on the machine stack are
> used.[1]
>>
>> Anyhow, it is not possible to change the stack (size) during a call to
>> pcre_exec() (unless, maybe, libpcre would be modified), and it is not
>> possible (to my knowledge) to calculate the required stack size in
>> advance.  The required stack size depends on pattern and subject.
>>
>> So basically, we have to call pcre_exec(), and if it fails due to
>> limited stack size, we either fail as well, or we try again.  In the
>> latter case we could either use a bigger stack or do without JIT.  In
>> the former case we should at least give users a setting to choose the
>> desired stack size, which is quite comparable to pcre.backtrack_limit
>> and pcre.recursion_limit.
>>
>> 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.
>>
>> [1] <http://www.pcre.org/original/doc/html/pcrejit.html#SEC8>
> 
> Only to be sure, ou mean it is a different issue than the common one (dozen
> of bugs for pcre about it)? Solved by increasing the stack size of the
> process or binary?

I'm pretty sure that is another issue.  The JIT functionality of libpcre
is available only for PHP 7, and the issue reported in #70110 only
happens when pcre.jit is enabled.  And to my knowledge #70110 is the
first reported bug that's caused by the JIT.

> Also an ini setting may not be portable. That's something to double check :)

ACK.  However, AFAICT pcre_jit_stack_alloc() and pcre_assign_jit_stack()
are supposed to be portable for systems where JIT support is available.

-- 
Christoph M. Becker