1900724 - Crash in [@ js::WasmArrayObject::isDataInline], possibly from general GC memory corruption

Status: NEW

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

Description

[BugBot [:suhaib / :marco/ :calixte]]

Crash report: https://crash-stats.mozilla.org/report/index/c5014d47-a733-480a-bc9e-4d8660240603

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  js::WasmArrayObject::isDataInline  js/src/wasm/WasmGcObject.h:298
0  xul.dll  js::WasmArrayObject::isDataInline const  js/src/wasm/WasmGcObject.h:300
0  xul.dll  js::WasmArrayObject::allocKind const  js/src/wasm/WasmGcObject-inl.h:171
0  xul.dll  JSObject::allocKindForTenure const  js/src/vm/JSObject.cpp:3230
1  xul.dll  JSObject::isBackgroundFinalized const  js/src/vm/JSObject.cpp:3178
1  xul.dll  js::DeadProxyTargetValue  js/src/proxy/DeadObjectProxy.cpp:140
2  xul.dll  js::NewDeadProxyObject  js/src/proxy/DeadObjectProxy.cpp:149
3  xul.dll  JS::Compartment::getNonWrapperObjectForCurrentCompartment  js/src/vm/Compartment.cpp:230
3  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:372
4  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:431

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2024-05-30
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 2 out of 3 crashes happened on null or near null memory address

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:rhunt, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Ryan Hunt [:rhunt]]

The case for wasm array object is the fallthrough case in allocKindForTenure [1], and has a debug assert that the object actually matches this assumption. I wonder if we would be tripping that assertion if it was a release assert. This logic changed in bug 1881019 pretty recently (late February) and these crashes started in April, which might line up with that getting released?

Jan, do you think my assessment above is possible?

Comment 3

[Jan de Mooij [:jandem]]

(In reply to Ryan Hunt [:rhunt] from comment #2)

The case for wasm array object is the fallthrough case in allocKindForTenure [1], and has a debug assert that the object actually matches this assumption. I wonder if we would be tripping that assertion if it was a release assert. This logic changed in bug 1881019 pretty recently (late February) and these crashes started in April, which might line up with that getting released?

Jan, do you think my assessment above is possible?

I agree. Before my change, the fallback case was NativeObject::allocKindForTenure and now it's WasmArrayObject::allocKind. This is most likely caused by memory corruption of the object or (base)shape. Changing this assertion to a release-assertion would make us crash more reliably in this case but it wouldn't stop the crashes.