Hi, > -----Original Message----- > From: David Zuelke [mailto:d...@heroku.com] > Sent: Monday, March 21, 2016 12:30 AM > To: Anatol Belski <anatol....@belski.net> > Cc: Christoph Becker <cmbecke...@gmx.de>; Pierre Joye > <pierre....@gmail.com>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PCRE JIT stack size limit > > > > On 20.03.2016, at 22:41, Anatol Belski <anatol....@belski.net> wrote: > > > > Hi, > > > >> -----Original Message----- > >> From: David Zuelke [mailto:d...@heroku.com] > >> Sent: Sunday, March 20, 2016 10:10 PM > >> To: Anatol Belski <anatol....@belski.net> > >> Cc: Christoph Becker <cmbecke...@gmx.de>; Pierre Joye > >> <pierre....@gmail.com>; PHP internals <internals@lists.php.net> > >> Subject: Re: [PHP-DEV] PCRE JIT stack size limit > >> > >>> On 17.03.2016, at 05:22, David Zuelke <d...@heroku.com> wrote: > >>> > >>>> On 16.03.2016, at 21:38, Anatol Belski <anatol....@belski.net> wrote: > >>>> > >>>> Hi, > >>>> > >>>>> -----Original Message----- > >>>>> From: David Zuelke [mailto:d...@heroku.com] > >>>>> Sent: Tuesday, March 15, 2016 11:58 PM > >>>>> To: Anatol Belski <anatol....@belski.net> > >>>>> Cc: Christoph Becker <cmbecke...@gmx.de>; Pierre Joye > >>>>> <pierre....@gmail.com>; PHP internals <internals@lists.php.net> > >>>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit > >>>>> > >>>>> Sure. So composer creates patterns to parse a file dynamically; I > >>>>> have not figured out why it only happens for some composer.json > >>>>> files (or maybe it happens for all of them and I just have not > >>>>> noticed), but this example here I extracted from a reproducibly > >>>>> failing "composer require" run; it runs into the JIT stack size > >>>>> limit > > on PHP 7 > >> while it works fine on 5.x: > >>>>> > >>>>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9 > >>>>> > >>>> I've just tried this on Debian Jessie and on Windows with the > >>>> latest > > 7.0.x > >> builds, in both cases the error is PREG_BACKTRACK_LIMIT_ERROR. I'd be > >> next asking you to check the configuration. Runtime like system or > >> ini, or > > build config > >> can affect this. Anyway, I don't see an issue with PCRE JIT at the moment. > >>> > >>> Sorry, I simplified the example too far. Updated it again to throw a > >>> JIT > > stack > >> limit error again (but works fine with "php -dpcre.jit=0"): > >>> > >>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9/de7b7293798ac57 > >>> b4 > >>> f75d822dc22a625be0fe9df > >> > >> Were you able to reproduce this? :) > >> > > Yes, it is reproducible. I was just investigating on another issue > > https://bugs.exim.org/show_bug.cgi?id=1803 which now seems unrelated. > > With the JIT stack - we can try to use a custom stack to increase its > > size by allocating a custom jit stack of an increased sizeas a > > workaround. If that works, it should be fine. I'll be working on a > > patch next week, then we can see this option makes sense. More on the > > topic is readable here > http://www.pcre.org/original/doc/html/pcrejit.html#stackcontrol . > > That sounds good. I suspect a significantly larger stack size than the PCRE > default of 32k will do the job for most cases. Arguably, what Composer uses > there is not a trivial pattern with all the nesting going on, but I was unable to > simplify it when I took a few minutes the other day, and while the > composer.json where the bug occurs is generated by code, I don't think it > qualifies as an extreme case. > 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.
> I guess though that some day, someone with a more complex pattern and/or > subject string will come with the same problem and say "this fails for me, the > 256k stack limit you set in PHP is not enough", so maybe an INI option should > exist? Although that's not terribly useful if one program needs it for one pattern. > Flags don't work well for this (unless it's e.g. a numeric one indicating multiples > of 128k or something, but that's also terrible). > The issue I have with more increasing the stack is that - while as we see till today the default stack size of 32K is enough in the common case, the max of it will be reserved. So the real usage will most likely stay under 32K, but the whole of max (say 64K now) will be unusable by anything else. > Or change the pcre_match (et al) implementations to retry without JIT if the > error occurs? > Yes, this were thinkable and doable within the scope of 7.0. A new INI option were however something for 7.1. The common case, at least till now, shows we beat more than 99% of PCRE usage with no compatibility issue. I'd plea therefore, to keep this simple for now and see whether the real life brings more issues with common projects. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
