Change #1091921 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMaintenance@master] Update Apache config syntax in .htaccess files

https://gerrit.wikimedia.org/r/1091921

Change #1091919 merged by jenkins-bot:

[mediawiki/extensions/Flow@master] Update Apache config syntax in .htaccess files

https://gerrit.wikimedia.org/r/1091919

Change #1187839 merged by jenkins-bot:

[mediawiki/extensions/Auth_remoteuser@REL1_39] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1187839

Change #1187834 merged by Jrchamp:

[mediawiki/extensions/Auth_remoteuser@REL1_40] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1187834

Change #1187839 had a related patch set uploaded (by Jrchamp; author: Umherirrender):

[mediawiki/extensions/Auth_remoteuser@REL1_39] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1187839

Change #1187834 had a related patch set uploaded (by Jrchamp; author: Umherirrender):

[mediawiki/extensions/Auth_remoteuser@REL1_40] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1187834

I see, I didn’t realize it was limited to just one xdebug mode that’s not even the most important one. With xdebug.mode=debug I still have a step debugger and the issue no longer happens.

We could document somewhere that running MW with xdebug requires xdebug.mode to not include develop. Could even throw an error if xdebug is loaded and this setting is incorrect.

I’m still able to reproduce the issue with uselang=he as well as uselang=pt; and thanks to @mszabo’s hint at T402278#11106001, I discovered that turning off xdebug seems to fix this issue. So this is almost certainly another issue caused by https://bugs.xdebug.org/view.php?id=2222, where xdebug messes with the lifetime of objects if an exception is thrown somewhere. (Indeed @Krinkle seems to have discovered it independently in T361419#10616730, which is the task linked from that bug report.)

The removal didn't end up happening in 1.42, so I filed T401532.

I also observed this bug and did a quick fix similar to T354800#9451835, it was on my TODO-list to report and fix it.
In fact it was fixed in MW 1.43+ by @daniel in Ie2e827d30a07 (patchset 7 specifically), so I mark this task as Resolved.

Change #1149492 merged by jenkins-bot:

[mediawiki/core@master] Require strings in OutputPage::setPageTitle()

https://gerrit.wikimedia.org/r/1149492

1.42 is now EOL.

Change #1160985 merged by jenkins-bot:

[mediawiki/extensions/Sudo@REL1_39] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1160985

Change #1160985 had a related patch set uploaded (by Reedy; author: Umherirrender):

[mediawiki/extensions/Sudo@REL1_39] Replace deprecated PersonalUrls hook

https://gerrit.wikimedia.org/r/1160985

Change #1149492 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Require strings in OutputPage::setPageTitle()

https://gerrit.wikimedia.org/r/1149492

Test wiki on Patch demo by 沈澄心 using patch(es) linked to this task was deleted:

Change #1101858 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@REL1_43] Avoid dynamic property for PHP 8.2 compatibility

https://gerrit.wikimedia.org/r/1101858

Change #1101859 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@REL1_42] Avoid dynamic property for PHP 8.2 compatibility

https://gerrit.wikimedia.org/r/1101859

Tag #ctt-attention on gerrit if you upload a patch for this. It looks like there are proposed fixes above. What would be really nice is a test case demonstrating the crash.

Change #1137090 merged by jenkins-bot:

[mediawiki/extensions/LiquidThreads@master] Use OutputPage::setPageTitleMsg() instead of ::setPageTitle() (#2)

https://gerrit.wikimedia.org/r/1137090

Change #1137090 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/LiquidThreads@master] Use OutputPage::setPageTitleMsg() instead of ::setPageTitle()

https://gerrit.wikimedia.org/r/1137090

I change the tags since as commented by @Alex44019 and myself, this issue occurs even without extensions.

In T366986#10637046, @Alex44019 wrote:

You're hitting ->parse() on whichever message is being parsed when you get the error, instead of ->preprocess(); the workaround for parse will look something like this:

		$this->mRevisionUser = $oldRevisionUser;
		$this->mRevisionSize = $oldRevisionSize;
		$this->mInputSize = false;
		$this->currentRevisionCache = null;
+
+		if ( $clearState ) {
+			$magicScopeVariable->__destruct();
+			ScopedCallback::cancel( $magicScopeVariable );
+		}

		return $this->mOutput;

You're hitting ->parse() on whichever message is being parsed when you get the error, instead of ->preprocess(); the workaround for parse will look something like this: