Closed Bug 1656335 Opened 5 years ago Closed 5 years ago

Perma [tier 2] tests/jit-test/jit-test/tests/wasm/no-movwt.js | /data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available (code 3, args "--wasm-compiler=baseline") [0.4 s]

Categories

(Core :: JavaScript: WebAssembly, defect, P5)

defect

Tracking

()

RESOLVED FIXED
81 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: lth)

References

(Regression)

Details

(Keywords: intermittent-failure, regression, Whiteboard: [retriggered])

Attachments

(1 file)

Filed by: csabou [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=311545816&repo=mozilla-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EFQUc14DRiqj8-QleNuibA/runs/0/artifacts/public/logs/live_backing.log


[task 2020-07-30T17:52:18.309Z] 17:52:12 INFO - TEST-PASS | tests/jit-test/jit-test/tests/wasm/no-movwt.js | Success (code 0, args "--wasm-compiler=ion") [0.5 s]
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - /data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - Stack:
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - @/data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17/data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - Stack:
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - @/data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17Exit code: 3
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - FAIL - wasm/no-movwt.js
[task 2020-07-30T17:52:18.309Z] 17:52:13 WARNING - TEST-UNEXPECTED-FAIL | tests/jit-test/jit-test/tests/wasm/no-movwt.js | /data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available (code 3, args "--wasm-compiler=baseline") [0.4 s]
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO exit-status : 3
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO timed-out : False
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stdout > /data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stdout > Stack:
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stdout > @/data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stderr 2> /data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17 Error: no WebAssembly compiler available
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stderr 2> Stack:
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - INFO stderr 2> @/data/local/tmp/test_root/tests/tests/tests/wasm/no-movwt.js:7:17
[task 2020-07-30T17:52:18.309Z] 17:52:13 INFO - TEST-PASS | tests/jit-test/jit-test/tests/wasm/no-movwt.js | Success (code 0, args "--test-wasm-await-tier2") [0.6 s]

Sure thing, will take care of it tomorrow morning.

This was indeed caused by bug 1645310 and should be corrected in this test case, as it's the test case that's wrong.

Assignee: nobody → lhansen
Status: NEW → ASSIGNED
Flags: needinfo?(lhansen)

What happens is that we start the shell with --wasm-compiler=baseline and load the test, which checks wasmIsSupported(). This is true, because the default hw flags on Pixel2 hardware have everything we need for this compiler; wasm::HasSupport() is true and there's at least one compiler available. So we run the script and set the flags to vfp. This disables the idiv flag and flags signifying the atomic opcodes. When we next get to lazy initialization of the WebAssembly object, wasm::HasSupport() will return false in the simulator only because HasSupport() checks Simulator::supportsAtomics(). Thus the test passes on simulator because the WebAssembly object is not created. But on hardware, we fall through to checking that we have at least one compiler that can compile wasm. The baseline compiler says no because idiv is not present, but ion says yes, since it's present (albeit not enabled) and does not have this restriction. So the WebAssembly object is created and compilation proceeds, but there are no compilers enabled and so we throw.

There are several ways to view this:

(a) The problem here really is the setARMHwCapFlags() method which basically screws with all attempts at initializing the engine in a reasonable way and maintaining a stable view on what the machine can do; on real hardware, we initialize the flags once and have a stable environment after that. Our code should be written with that in mind. Test cases that violate that, whether fuzzing tests or tests mucking with the flags, should be forced to adapt.

(b) The problem here really is that we're not checking the atomics flags (or its proxy) also on hardware. We should do deeper checking of hardware in HasSupport.

(c) The problem here really is that we're not taking into account whether a compiler is enabled when we check HasSupport. We should do deeper checking of compilers in HasSupport.

(d) The problem here really is that HasSupport has a variable answer. We should cache the answer and always reuse it.

As far as (c) and (d) are concerned, these are not the right answer. The reality of the environment, with about:config being exposed to users and the debugger coming and going, is that it is variable. Bug 1645310 made the presence of the WebAssembly object independent of whether the debugger had been activated or not, but there's only so much we can do when somebody flips a switch that pertains to what the hardware can do. (We could discuss this. The WebAssembly object could be present on every platform that supports wasm in principle, ie, not dependent on HasSupport, and we could throw instead, whenever some assumption is violated. It's not obvious to me that this is better than what we have, but it's also not obvious that it's worse.)

I think (b) may be relevant: we should be checking that the hw flags are sensible. We have a history of allowing nonsensical values for the ARM hw flags, and wasm really should be gated on some reasonably minimal set. The supportsAtomics() call is just HasLDSTREXBHD() which is common for all ARM platforms, simulator or not; calling this instead would have saved us here.

I think (a) is definitely relevant: test cases that muck with the hardware flags should be prepared for the consequences.

There's also (e): The test case does not make sense any more. Nothing's gated on movw or movt, though the baseline compiler gates on idiv and all compilers should gate on atomic operations. I think renaming and refocusing this test case would be useful.

Set release status flags based on info from the regressing bug 1645310

Attachment #9167257 - Attachment description: Bug 1656335 - Improve wasm gating on ARM → Bug 1656335 - Improve wasm gating on ARM. r?jseward
Whiteboard: [retriggered]
Blocks: 1656832
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: