Intermittent /builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9 Error: Assertion failed: got "baseline", expected "optimized"
Categories
(Core :: JavaScript: WebAssembly, defect, P5)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: jseward)
Details
(Keywords: assertion, intermittent-failure)
Attachments
(1 file)
Filed by: abutkovits [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=537453695&repo=autoland&task=Ft-jCw5fQXKKw1KgT_TUHQ.0
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ft-jCw5fQXKKw1KgT_TUHQ/runs/0/artifacts/public/logs/live_backing.log
[task 2025-11-26T10:05:27.984+00:00] TEST-PASS | js/src/jit-test/tests/wasm/errors.js | Success (code 0, args "") [0.4 s]
[task 2025-11-26T10:05:27.984+00:00] /builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9 Error: Assertion failed: got "baseline", expected "optimized"
[task 2025-11-26T10:05:27.984+00:00] Stack:
[task 2025-11-26T10:05:27.984+00:00] @/builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9
[task 2025-11-26T10:05:27.984+00:00] Exit code: 3
[task 2025-11-26T10:05:27.984+00:00] FAIL - wasm/excessive-inlining.js
[task 2025-11-26T10:05:27.984+00:00] TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/wasm/excessive-inlining.js | /builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9 Error: Assertion failed: got "baseline", expected "optimized" (code 3, args "--ion-eager --ion-offthread-compile=off --more-compartments") [0.3 s]
[task 2025-11-26T10:05:27.984+00:00] INFO exit-status : 3
[task 2025-11-26T10:05:27.984+00:00] INFO timed-out : False
[task 2025-11-26T10:05:27.984+00:00] INFO stderr 2> /builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9 Error: Assertion failed: got "baseline", expected "optimized"
[task 2025-11-26T10:05:27.984+00:00] INFO stderr 2> Stack:
[task 2025-11-26T10:05:27.984+00:00] INFO stderr 2> @/builds/worker/checkouts/gecko/js/src/jit-test/tests/wasm/excessive-inlining.js:58:9
[task 2025-11-26T10:05:27.984+00:00] TEST-PASS | js/src/jit-test/tests/wasm/errors.js | Success (code 0, args "--wasm-compiler=baseline") [0.3 s]
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•2 months ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 5•1 month ago
|
||
This test is failing intermittently. Can you take a look? It seems like the design of this assertion isn't exactly reliable because it depends on timing assumptions. I've seen it locally fail on really slow machines. Could we redesign this?
| Comment hidden (Intermittent Failures Robot) |
|
Assignee | |
Comment 7•1 month ago
|
||
This is a lousy test, I agree, but I can't think of a simple way to improve it.
It attempts to check that the excessive-inlining cutoff mechanism is
functional, by racing (off-thread) Ion compilation of function recursive
against a run of it (which serves also to trigger Ion compilation). We expect
the cutoff mechanism to kick in and thereby limit Ion compilation time, so
that, after running the function is done, we can assert that the function has
been tiered up (because Ion compilation finished relatively quickly.)
This is bad for all the reasons that critical races in programs are bad.
I suppose one hack would be to increase the workload that Ion races against, to
give Ion more time in the case that it lags behind. This is still racey
though. Maybe just run recursive(10) twice.
A robust fix would involve the JS driver being able to query, after the
recursive(10) call is done, whether there have been any inlining-cutoffs for
the current module. Do we have any mechanism to allow JS-land to query Ion
optimization behaviour? This would be possible if it were possible to get hold
of the MOZ_LOG=wasmPerf:3 output in JS, since that contains details of
inlining-cutoffs.
|
|
||
Comment 8•1 month ago
|
||
We have wasmDumpIon [1] which gives you a JSON dump of the MIR which you can analyze. I'm not sure how it works with inlining, it might disable it or start with empty inlining limits.
Another option would be to use wasmMetadataSize to see how many code bytes are being used.
We theoretically could add a new testing function which return the current inlining thresholds for a module, and you could use that to check if the limits have been reached. That's probably the most robust.
TBH though, I sort of wonder if we should just get rid of the test. I'm not sure if it provides enough value to be worth adding dedicated testing functions for.
| Comment hidden (Intermittent Failures Robot) |
|
|
Assignee | |
Comment 10•8 days ago
|
||
js/src/jit-test/tests/wasm/excessive-inlining.js is poorly designed, being
timing-dependent and hence failing intermittently, especially on slow machines.
It is nevertheless important in that it checks that Ion's wasm-inlining-budget
machinery works.
This patch reimplements it to be race-free. Code::metadataAnalysis() can now
return to JS, the sizes of the Tier-1 and -2 code, and these can be used as the
basis for checking that inlining budgets work. There are also a number of
reference sizes documented as an aid to future development/changes here.
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 12•15 hours ago
|
||
|
||
Comment 13•11 hours ago
|
||
| bugherder | ||
Description
•