1817782 - Kotlin example crashes with Wasm GC

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect)

Description

[bashor]

Attachment: dbmonster.zip

Steps to reproduce:

1. Unzip an attached zip
2. Start a server to serve files from the dir, like python -m http.server
3. Open in the Firefox Nightly 112.0a1 (2023-02-20) (64-bit)

Actual results:

Got "Gah. Your tab just crashed."

Expected results:

It works and shows something like http://webreflection.github.io/dbmonster/

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[bashor]

JFTR: it may related to https://bugzilla.mozilla.org/show_bug.cgi?id=1812132

Comment 3

[Ryan Hunt [:rhunt]]

There is at least one issue here where we're performing a cast on a non-WasmGcObject which is causing a crash. I have a fix for that, but it uncovered another issue I'm looking into.

Comment 4

[Ryan Hunt [:rhunt]]

Attachment: Bug 1817782 - wasm: Test that we're only casting WasmGcObject. r?jseward

The casting instructions currently assume that the input anyref is
just a WasmGcObject (either struct or array). However any JS Value
can become an anyref through extern.internalize. These values do
not have a typedef field and must checked for while casting.

This adds extra bloat to our casting instructions that we should
find a way to remove. Two options:

1. Move the typedef from the object to the shape. This would
   add an extra indirection to casting though.
2. Box non-WasmGcObject's in a WasmStructObject when extern.
   internalize is called.

Comment 5

[Ryan Hunt [:rhunt]]

Attachment: Bug 1817782 - wasm: Fix register allocation of br_on_cast in baseline. r?jseward

Values that are used for a branch in baseline cannot be allocated
in the integer result registers as those will be used for transmitting
results to the next block.

There are two tweaks in br_on_cast needed:

1. Stop pushing the object to the value stack but still using it in the
   branch code, as that violates the baseline invariants which assume that
   any register on the value stack can be sync'ed and then used for a
   different purpose.
2. Ensure we don't allocate any registers to the result registers while
   we're setting up the branch.

Depends on D170708

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/880728840fdd
wasm: Test that we're only casting WasmGcObject. r=jseward
https://hg.mozilla.org/integration/autoland/rev/6457eabafda2
wasm: Fix register allocation of br_on_cast in baseline. r=jseward
https://hg.mozilla.org/integration/autoland/rev/b2905862fca3
apply code formatting via Lando

Comment 7

[Sandor Molnar[:smolnar]]

Backed out for causing spider-monkey failures in js/src/jit-test/tests/wasm/gc/cast-extern.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/5eb81f0156a80fd113309e1a4671c134d0bc4615

Push with failures

Failure log -> TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/wasm/gc/cast-extern.js | /builds/worker/checkouts/gecko/js/src/jit-test/lib/wasm.js:52:13 CompileError: at offset 14: bad type (code 3, args "--wasm-function-references --wasm-gc

Comment 8

[Julian Seward [:jseward]]

It might be that the backout was caused by bug 1819351 [the command-line-parsing bug]
not having landed before this one? Just guessing.

Comment 9

[Ryan Hunt [:rhunt]]

Ah, the test uses a SIMD type and that's not supported on ARM32.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6e74a9817cbf
wasm: Test that we're only casting WasmGcObject. r=jseward
https://hg.mozilla.org/integration/autoland/rev/d3d9e99c352a
wasm: Fix register allocation of br_on_cast in baseline. r=jseward

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/6e74a9817cbf
https://hg.mozilla.org/mozilla-central/rev/d3d9e99c352a