On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski <anatol....@belski.net> wrote:
> 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. > Are you sure about that? The documentation says "The arguments are a starting size for the stack, and a maximum size to which it is allowed to grow." Unless I'm misunderstanding something, it should not be allocating the maximum size right away. Nikita > > 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 > >
