| Anomie added a comment. |
In T143389#2568039, @greg wrote:@Anomie: can you help me understand what this test is trying to test for and what it means that it is now failing (iow: a failing test should imply broken code: where's the broken code?).
Scribunto has a feature where it limits the total CPU time used to a configurable limit, to prevent a module from running indefinitely during the parse.
Some things that nominally occur "inside" Lua really should not be counted against this time limit. For example, the wikitext {{#invoke:MyModule|myFunc| {{some template}} }} calls the function myFunc in Module:MyModule, passing as a parameter the expanded wikitext of {{some template}}. For performance, however, MediaWiki does not actually expand the wikitext for {{some template}} until it's actually accessed inside MyModule. Per T47684: getExpandedArguments should not count toward the 10-second Lua execution limit, this argument expansion time should not be counted against the time limit. On the other hand, if something inside MyModule parses wikitext instead of having it passed in as an argument, the time inside that recursive parse should count against the time limit.
This test verifies that the time is accounted as described above, i.e. that Scribunto calls luasandbox's pauseUsageTimer() and unpauseUsageTimer() in the right places to get the proper outcome. It does that by constructing a simple version of {{some template}} that is intended to reliably use 0.500s of CPU time, then asks Scribunto how much CPU time was actually measured. In the cases where the argument expansion time should not be counted, Scribunto should have only accounted somewhere around 0.001s. The test itself checks whether accounted time is more or less than 0.250s.
This task is about the fact that something in WMDE's CI infrastructure is causing Scribunto to measure accounted time far in excess of 0.001s during this test. I can think of a few possibilities, but nothing that gives me something to do about it:
- luasandbox appears to count both 'user' and 'system' time, while the test only checks 'user' time when implementing the delay. But that shouldn't cause the test to fail: it would make the delay longer than 0.5s of total CPU time, but that shouldn't matter when it's not supposed to be counted and the cases where it is counted aren't the problem here.
- There might be a bug in luasandbox that makes it count time incorrectly. As far as I know, though, we've never run into this on WMF's CI infrastructure and I've never seen it in local testing, so I have no way to begin reproducing it to test this hypothesis.
- WMDE's CI infrastructure might be using a version of luasandbox compiled without the presence of the CLOCK_THREAD_CPUTIME_ID constant for clock_gettime(), in which case it would measure wall time rather than CPU time. I have no way to check this.
- WMDE's virtualized CI infrastructure might be emulating a system with a variable clock speed, so sometimes instead of a 2GHz processor it's running a 2KHz processor. That could cause even parts of the code that normally take only 0.001s to take radically more time than that due to the excessively slow processor. I have no way to test this.
- WMDE's virtualized CI infrastructure might have buggy POSIX clock or timer behavior in the virtualized environment that somehow breaks luasandbox's accounting. For example, it might implement CLOCK_THREAD_CPUTIME_ID in terms of wall clock time or host CPU time instead of virtualized environment CPU time. I have no way to test this either.
- WMDE's virtualized CI infrastructure might have bugs that cause it to randomly block for relatively long periods of time in system calls in a way that still counts as system time used. I have no way to test this either.
- Something involved in one of their extensions being tested in conjunction with Scribunto might be causing extreme slowdowns in parts of the code outside the bit that's specifically not accounted. It seems unlikely that they wouldn't have noticed this themselves, and I wouldn't know where to begin to even start with testing that theory.
Cc: greg, gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
