On Thu, Jan 20, 2022 at 09:42:47AM -0800, Bryce Harrington wrote:
> On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> > Hi Kunal,
> >
> > Thanks for the analysis.
> >
> > On 20-01-2022 10:56, Kunal Mehta wrote:
> > > > I can't tell what it may be trying to encode, but presumably it's either
> > > > Main_Page or something used by Main_Page, which I'm guessing should only
> > > > take a fraction of a second to encode. I suppose we could test
> > > > increasing max_execution_time. But my suspicion is that the encoder is
> > > > getting stuck in a loop or a recursion.
> > >
> > > 30 seconds seems a bit absurd, but given an empty opcache/jit, empty
> > > caches, on 32-bit VMs, it's within the realm of possibility...I think
> > > bumping max_execution_time is a good next step. Should the test add a
> > > php.ini snippet or something?
> >
> > I think that would be great. But please upload to Debian as well, let's not
> > only have these tests in Ubuntu.
> >
> > > I read through the 8.1 changelog
> > > (<https://www.php.net/ChangeLog-8.php#PHP_8_1>) and couldn't find
> > > anything relevant that wasn't already in PHP 8.0.8 (specifically
> > > <https://github.com/php/php-src/commit/bf9dc534356ec3b372abe5f3030c3e362aa261ac>
> > > looked suspect, but that was included in 8.0.7).
> >
> > In Debian we're going from 7.4 to 8.1, so all intermediate upstreams are
> > relevant.
> >
> > > Just to give some expectations, I won't have time to dig into this until
> > > the weekend. I did drop a pointer to the bug in the MediaWiki developers
> > > IRC channel in case anyone there had suggestions.
> >
> > Can that php.ini addition to the test happen thought, or is even that to
> > much of your time? (Not blaming, just asking).
>
> I've not tried it myself but the web suggests this might also be
> controllable on a per-test basis via patching the test with something
> like:
>
> ini_set('max_execution_time', '300');
I've kicked off a test with this, to see if adjusting the timeout would
be worth considering as a possible solution.
Probably unrelated but in prepping the changes I noticed this lintian
complaint:
Warning in processable ./mediawiki_1.35.5-1ubuntu3.dsc: Complex regular
subexpression recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
Bryce
> Another option, which might be more suitable for a self-contained dep8
> test than a patch, would be an .htaccess file, with a line like:
>
> php_value max_execution_time 300
>
> ref:
> https://stackoverflow.com/questions/8744107/increase-max-execution-time-in-php
>
> Poking around a bit on SO, it does appear that hitting json_encode
> timeouts is a thing:
>
> https://stackoverflow.com/questions/36975512/maximum-execution-time-exceeded-on-json-decode
> https://stackoverflow.com/questions/5164930/fatal-error-maximum-execution-time-of-30-seconds-exceeded
> https://stackoverflow.com/questions/1263680/maximum-execution-time-in-phpmyadmin
> https://stackoverflow.com/questions/7680572/fatal-error-maximum-execution-time-of-300-seconds-exceeded
>
> Adjusting max_execution_time seems to be the commonly suggested solution
> across the board.
>
> Bryce
