Hi Christoph,
> -----Original Message-----
> From: Christoph Becker [mailto:[email protected]]
> Sent: Thursday, July 23, 2015 8:47 PM
> To: Pierre Joye <[email protected]>
> Cc: PHP internals <[email protected]>
> 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