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).

Paul

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to