Page MenuHomePhabricator

fix flaky test LuaSandbox: Scribunto_LuaSandboxTests::testArgumentParsingTime Recursive argument access time was counted
Closed, ResolvedPublic


Wikidata test run

06:11:14 1) LuaSandbox: Scribunto_LuaSandboxTests::testArgumentParsingTime
06:11:14 Recursive argument access time was counted
06:11:14 Failed asserting that 0.24770367 is greater than 0.25.
06:11:14 /mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/extensions/Scribunto/tests/engines/LuaSandbox/SandboxTest.php:75
06:11:14 /mnt/jenkins-workspace/workspace/mwext-testextension-hhvm/src/tests/phpunit/MediaWikiTestCase.php:137

See also T111075.

Event Timeline

JanZerebecki raised the priority of this task from to Needs Triage.
JanZerebecki updated the task description. (Show Details)
JanZerebecki added a subscriber: JanZerebecki.

That's an odd failure, since the time taken should be much closer to 0 on failure and much closer to 0.5 seconds on success. Something must have somehow managed to pause the process or otherwise interrupt CPU time accounting for almost exactly 0.25 seconds during the execution of this bit of code:

$t = microtime( 1 ) + 0.5;
while ( microtime( 1 ) < $t ) {
    # Waste CPU cycles

Is this reliably flaky, or did it happen just the once? See also T111075#1593802.

It only happened once. Thx for pointing out the code, so one of those is real time, the other is CPU time. As in this case only real >= CPU is always true, I think that qualifies as flaky. Though I have no good idea how to ensure we spend x amount of cpu time on any system (no matter how fast).

Change 270023 had a related patch set uploaded (by Anomie):
Waste CPU cycles, not wall clock time

Change 270023 merged by jenkins-bot:
Waste CPU cycles, not wall clock time

JanZerebecki claimed this task.