Closed Bug 1521058 Opened 7 months ago Closed 7 months ago

Crash in js::wasm::CompilerEnvironment::computeParameters

Categories

(Core :: Javascript: WebAssembly, defect, critical)

Unspecified
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla66
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed

People

(Reporter: calixte, Assigned: luke)

Details

(Keywords: crash, regression, Whiteboard: [arm64:m2])

Crash Data

Attachments

(1 file)

This bug is for crash report bp-fc4e2c53-6126-42ff-aa42-d74480190118.

Top 10 frames of crashing thread:

0 libxul.so js::wasm::CompilerEnvironment::computeParameters js/src/wasm/WasmCompile.cpp:436
1 libxul.so js::wasm::DecodeModuleEnvironment js/src/wasm/WasmValidate.cpp:2430
2 libxul.so js::wasm::CompileBuffer js/src/wasm/WasmCompile.cpp:529
3 libxul.so js::wasm::DeserializeModule js/src/wasm/WasmModule.cpp:427
4 libxul.so JS::DeserializeWasmModule js/src/jsapi.cpp:6027
5 libxul.so mozilla::dom::indexedDB::BackgroundRequestChild::PreprocessHelper::ProcessCurrentStream dom/indexedDB/ActorsChild.cpp:3107
6 libxul.so mozilla::dom::indexedDB::BackgroundRequestChild::PreprocessHelper::Run dom/indexedDB/ActorsChild.cpp:3187
7 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp
8 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:241
9 libxul.so non-virtual thunk to nsThreadPool::Run xpcom/threads/nsThreadPool.cpp

There are 19 crashes (from 10 installations) in nightly 66 starting with buildid 20190115103851.

:luke, could you investigate please ?

Flags: needinfo?(luke)

So we're on the goofy dead-once-bug-1487479-lands IDB path. Looks like the CompileArgs we create has ionEnabled = baselineEnabled = false. The CompilerEnvironment computation flips on ion if baseline is disabled, but on arm64 there is no ion, so that leaves us with no compiler.

Assignee: nobody → luke
Flags: needinfo?(luke)
Attachment #9037574 - Flags: review?(lhansen)

Note that this crash can/does only hit on arm64. It's shocking that they have a serialized wasm Module at all; I wonder if it's someone running our wasm IDB test or something.

Comment on attachment 9037574 [details] [diff] [review]
fix-idb-deserialization

Review of attachment 9037574 [details] [diff] [review]:
-----------------------------------------------------------------

OK :-)  The lack of a context with real information / real plumbing during deserialization is a continuing source of pain, though.
Attachment #9037574 - Flags: review?(lhansen) → review+

You're right. Bug 1487479 should kill this whole function (b/c there will never be a wasm Module in IDB to deserialize). With new HTTP caching (bug 1487113), we never recompile on the deserialize path; we just fail to get a machine-code-cache hit, so I think this category of problem goes away.

This is the top crash on ARM64 Fennec.

Whiteboard: [arm64:m2]
Pushed by lwagner@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dd45dce4d3a9
Baldr: fix IDB deserialization flags on arm64 (r=lth)

Weird; that non-unified build error doesn't repro locally. Fortunately obvious fix adding associated headers.

Flags: needinfo?(luke)
Pushed by lwagner@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd64d6e1a11b
Baldr: fix IDB deserialization flags on arm64 (r=lth)
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.