In T361419#10616730, @Krinkle wrote:

I've found another example of Xdebug's object retention causing tests to fail. As of late, I can't get composer phpunit tests/phpunit/includes/language/MessageTest.php to pass locally.

This can happen with non-exceptions as well (e.g. T389801: [error/html2wt] Input DOM is not well-formed. Top-level <li> found that is not nested in <ol>/<ul>\n LI-node). I think it should be handled by LogstashFormatter.

I've found another example of Xdebug's object retention causing tests to fail. As of late, I can't get composer phpunit tests/phpunit/includes/language/MessageTest.php to pass locally.

In T385965#10534315, @Maltfield wrote:

a temporary workaround for this bug is to add the following to the top of your LocalSettings.php file (before any require() or include()s)

76f36c1bbcafeeb26876f71106715d55d19e7323 against T384905: Class Flow\Exception\InvalidDataException does not exist / Declaration of Flow\Exception\FlowException::__construct should be compatible with Wikimedia\NormalizedException\NormalizedException::normalizedConstructor; part of v2.0.2

Change #1114692 merged by jenkins-bot:

[mediawiki/libs/RequestTimeout@master] composer.json: Run phpunit as part of 'composer test'

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

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

[mediawiki/libs/RequestTimeout@master] composer.json: Run phpunit as part of 'composer test'

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

Sorry for the confusion, this isn't a feature, and isn't our code that's at fault.

Looks like this already got reported as https://bugs.xdebug.org/view.php?id=2222. The author does not seem to be particularly swayed by it though...

Minimal reproducer:

php
<?php

We investigated further with @Krinkle today. Our results are follows:

• To reproduce, one needs to have XDebug loaded with xdebug.mode containing develop. Excimer does not appear to play any role.
• Xdebug 3.3.0 shipped a new feature of adding a from_exception option to xdebug_get_function_stack to return the stack trace where an exception was thrown. Internally, this functionality works by stashing local variables and other context alongside the trace for the last eight exceptions to have been thrown, implemented in https://github.com/xdebug/xdebug/pull/903.

I couldn't reproduce this, with PHP 8.2.15, xdebug disabled, and excimer locally compiled from the current git master.

CriticalSectionScope is not meant to be alive until the end of the process. That's the whole point of it, to have scope lifetime.

Pinging @tstarling , because Eximer

Given that php-xdebug, by definition, cannot be used to debug this problem, time to sprinkle some print, wfBacktrace, and var_dump:

The exception doesn't quite make sense as the class obviously exists. Perhaps an opcache fluke or something that corrupts/prevents the autoloader from working correctly? In any event, it's an downstream exception from another exception that's the main cause so less urgent in that regard as it would fatal either way, it's a failure to report the failure in one way and instead gets reported another way.

I don't think this is related to PageViewInfo (other than that it times out - see T324675: UserImpact: Fetch information for more articles when calculating most-viewed-articles data point for context on that).