Hi Christoph,

> -----Original Message-----
> From: Christoph Becker [mailto:cmbecke...@gmx.de]
> Sent: Thursday, July 23, 2015 8:47 PM
> To: Pierre Joye <pierre....@gmail.com>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
> 
> 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>
> 
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to