Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91829
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 74.125.82.42 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <0b5101d183a1$5b38fdd0$11aaf970$@belski.net>
Date: Mon, 21 Mar 2016 22:51:37 +0100
Cc: Christoph Becker <cmbecker69@gmx.de>,
 Pierre Joye <pierre.php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <92DFDA3A-A52E-4435-BCC5-D67F855382AD@heroku.com>
References: <55B0CADD.8000807@gmx.de> <CAEZPtU7aPzPQ=DL5fn9fOEuU_hySm5WXUkbjFw+Sq0T5xNfb3A@mail.gmail.com>
 <55B136BE.8010006@gmx.de> <046401d0c644$9cf76880$d6e63980$@belski.net>
 <55B2B78A.4080202@gmx.de> <048001d0c665$ed19ec40$c74dc4c0$@belski.net>
 <55B2D779.9090409@gmx.de> <04d301d0c6e5$6b28f0c0$417ad240$@belski.net>
 <55B3B2E6.7080905@gmx.de> <056e01d0c7d9$b1edd990$15c98cb0$@belski.net>
 <55B559C7.9060304@gmx.de> <064301d0c85f$5260ac60$f7220520$@belski.net>
 <55C008B1.2050008@gmx.de> <05ec01d0ce97$4ee7c4e0$ecb74ea0$@belski.net>
 <55C09EE2.7010400@gmx.de> <063f01d0cec2$91b9baf0$b52d30d0$@belski.net>
 <55C0F908.2050708@gmx.de> <068e01d0cefb$6ffba3e0$4ff2eba0$@belski.net>
 <A428AF35-A176-404D-888C-7541100155B2@heroku.com> <016e01d17ef7$cd8a2660$689e7320$@belski.net>
 <25D67B35-88FF-4A5C-9421-BAF482B32A96@heroku.com> <036501d17fc3$d51357e0$7f3a07a0$@belski.net>
 <5E36AA30-831F-44BE-A148-8720B8E87E96@heroku.com> <94A89B0F-48BB-4DD8-A26B-3B6D2C8C2C9F@heroku.com>
 <099201d182f1$3c954600$b5bfd200$@ belski.net> <7 DF19331-9967-47C8-B21D-260C619BBD5E@heroku.com>
 <0b5101d183a1$5b38fdd0$11aaf970$@belski.net>
To: Anatol Belski <anatol.php@belski.net>
Subject: Re: [PHP-DEV] PCRE JIT stack size limit
From: dz@heroku.com (David Zuelke)

On 21.03.2016, at 19:41, Anatol Belski <anatol.php@belski.net> wrote:
> I've just pushed a fix for this issue, could you please check? A =
global
> stack space
> Is used in a thread safe manner. I was first setting max to 256K, then
> decreased it
> To 64K for now. My tests on Linux and Windows show your snippet =
passing,
> Travis is good as well.

Just tested; that fix works for my specific test case, thanks!

However, if I just increase the size of the JSON by adding a bunch of =
package definitions, it starts failing again, so this really is just a =
temporary band-aid, and we should consider falling back to retrying =
without JIT, or switching that off by default in php.ini.

The particular composer.json I showed is generated on deploy based on a =
customers' composer.lock (to correctly resolve PHP versions and =
extensions to be installed), and there will be a day when a customer =
with more dependencies comes along (or maybe that's already happened and =
they just have not filed a ticket), which means the 64k again won't be =
enough.

My workaround for now is to disable pcre.jit via php.ini, but maybe that =
really should be the default.

Regards,

David