1521058 - Crash in js::wasm::CompilerEnvironment::computeParameters

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect)

Description

[Calixte Denizet (:calixte)]

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 ?

Comment 1

[Luke Wagner [:luke]]

Attachment: fix-idb-deserialization

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.

Comment 2

[Luke Wagner [:luke]]

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 3

[Lars T Hansen [:lth]]

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.

Comment 4

[Luke Wagner [:luke]]

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.

Comment 5

[Chris Peterson [:cpeterson]]

This is the top crash on ARM64 Fennec.

Comment 6

[Pulsebot]

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

Comment 7

[Andrei Ciure[:aciure]]

Backed out changeset dd45dce4d3a9 (bug 1521058) for causing WasmModule.cpp build bustage

push that caused the failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=dd45dce4d3a9e37af40b36e631ffc9841817a3a0

failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&selectedJob=222780751&searchStr=linux%2Cx64%2Cdebug%2Cspidermonkey%2Cbuilds%2Cspidermonkey-sm-nonunified-linux64%2Fdebug%2Csm%28nu%29

backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/afa74c85b798b212b7ba836c818ee876122fb4fa

Comment 8

[Luke Wagner [:luke]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd64d6e1a11b
Baldr: fix IDB deserialization flags on arm64 (r=lth)

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/bd64d6e1a11b