Closed Bug 1521058 Opened 2 years ago Closed 2 years ago

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


(Core :: Javascript: WebAssembly, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed


(Reporter: calixte, Assigned: luke)


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

Crash Data


(1 file)

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

Top 10 frames of crashing thread:

0 js::wasm::CompilerEnvironment::computeParameters js/src/wasm/WasmCompile.cpp:436
1 js::wasm::DecodeModuleEnvironment js/src/wasm/WasmValidate.cpp:2430
2 js::wasm::CompileBuffer js/src/wasm/WasmCompile.cpp:529
3 js::wasm::DeserializeModule js/src/wasm/WasmModule.cpp:427
4 JS::DeserializeWasmModule js/src/jsapi.cpp:6027
5 mozilla::dom::indexedDB::BackgroundRequestChild::PreprocessHelper::ProcessCurrentStream dom/indexedDB/ActorsChild.cpp:3107
6 mozilla::dom::indexedDB::BackgroundRequestChild::PreprocessHelper::Run dom/indexedDB/ActorsChild.cpp:3187
7 mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp
8 nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:241
9 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]

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
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
Baldr: fix IDB deserialization flags on arm64 (r=lth)
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.