Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87260
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55B136BE.8010006@gmx.de>
References: <55B0CADD.8000807@gmx.de>
	<CAEZPtU7aPzPQ=DL5fn9fOEuU_hySm5WXUkbjFw+Sq0T5xNfb3A@mail.gmail.com>
	<55B136BE.8010006@gmx.de>
Date: Fri, 24 Jul 2015 14:17:28 +0700
Message-ID: <CAEZPtU6ofjJsueh+f-uyCo1Cci6pfiMGjHVnAODxLizqVOwtnw@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c11776e6bf69051b99cbfc
Subject: Re: [PHP-DEV] PCRE JIT stack size limit
From: pierre.php@gmail.com (Pierre Joye)

--001a11c11776e6bf69051b99cbfc
Content-Type: text/plain; charset=UTF-8

On Jul 23, 2015 9:47 PM, "Christoph Becker" <cmbecker69@gmx.de> wrote:
>
> Hi Pierre,
>
> Pierre Joye wrote:
>
> > Hi Christoph,
> >
> > There are ways to dymacally increase the stack. Apache's modphp can use
the
> > apache config. Fpm, fcgi or cli can change it on windows (afair it is in
> > the doc). It is possible too on Linux with ulimit.
> >
> > An alternative (not a big fan) would be to use setrlimit with an ini
> > setting.
>
> 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?

Also an ini setting may not be portable. That's something to double check :)
Cheers,
Pierre

> --
> Christoph M. Becker

--001a11c11776e6bf69051b99cbfc--