Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87276
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Christoph Becker'" <cmbecker69@gmx.de>,
	"'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>
In-Reply-To: <55B136BE.8010006@gmx.de>
Date: Fri, 24 Jul 2015 21:11:55 +0200
Message-ID: <046401d0c644$9cf76880$d6e63980$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHD9RJvenw/Ss5kSkuHSfZFOrs2uQBWRtPIAqC4oYSd649jwA==
Content-Language: en-us
Subject: RE: [PHP-DEV] PCRE JIT stack size limit
From: anatol.php@belski.net ("Anatol Belski")

Hi Christoph,

> -----Original Message-----
> From: Christoph Becker [mailto:cmbecker69@gmx.de]
> Sent: Thursday, July 23, 2015 8:47 PM
> To: Pierre Joye <pierre.php@gmail.com>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>=20
> Hi Pierre,
>=20
> Pierre Joye wrote:
>=20
> > 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.
>=20
> 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]
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> [1] <http://www.pcre.org/original/doc/html/pcrejit.html#SEC8>
>=20
This looks like an extremely fragile topic because it depends on how =
much stack is available to an executable. A custom JIT stack can behave =
more stable but cannot be resized. And the main issue is that the JIT =
stack size, machine stack size and ext/pcre cache size are completely =
unrelated terms. For example, a binary can have not enough stack, but =
the custom JIT stack using mmap/VirtualAlloc could even succeed, but =
then pcre_exec will be executed and overflow the machine stack. We can =
never know which one is exhausted first - the one for the JIT =
compilation or the other one for the execution, or vice versa.

Generally, moving the JIT compilation away from the machine stack and =
increasing the PCRE cache size should be more stable against this . =
However it's an edge case. IMHO we should not do it just to fix some =
crazy usage. Users who need it might just turn off JIT. Normal usage =
seems not to be affected, say loading some sane functional script, which =
FE is done by any benchmark with WP, Symfony, etc. But moving JIT =
compilation away from the machine stack wil lpossibly affect it.

Regards

Anatol