> 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/de7b7293798ac57b4 >>> 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 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). Or change the pcre_match (et al) implementations to retry without JIT if the error occurs? David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
