Bug 283476 – Inconsistent CompileError in WebAssembly Module Compilation

• Component: New Bugs
• Status: REOPENED

Created attachment 473306 [details]
poc.js

When attempting to compile a WebAssembly module using the JSC engine, two different CompileError outcomes were observed. These errors occur intermittently when running the same script.

WebKit Engine (Git a6d261838dcb9f9e9c7bad991bc3d880ae5358ee):
Command:
```bash
./jsc ./test.js
```
Output:
```
./jsc ./bug_6.js
Exception: CompileError: WebAssembly.Module doesn't parse at byte 67: can't get heap type for ref.cast, in function at index 2 (evaluating 'new WebAssembly.Module(wasm_code)')
Module@[native code]
global code@./bug_6.js:2:41
./jsc ./bug_6.js
Exception: CompileError: WebAssembly.Module doesn't parse at byte 57: byte alignment 4 does not match against atomic op's natural alignment 4, in function at index 1 (evaluating 'new WebAssembly.Module(wasm_code)')
Module@[native code]
global code@./bug_6.js:2:41
```

Another example
```
./jsc ./bug_5.js 
Exception: CompileError: WebAssembly.Module doesn't parse at byte 84: call function index 0 has 3 arguments, but the expression stack currently holds 2 values, in function at index 0 (evaluating 'new WebAssembly.Module(wasm_code)')
Module@[native code]
global code@./bug_5.js:2:41

./jsc ./bug_5.js 
Exception: CompileError: WebAssembly.Module doesn't parse at byte 201: byte alignment 4 does not match against atomic op's natural alignment 4, in function at index 1 (evaluating 'new WebAssembly.Module(wasm_code)')
Module@[native code]
global code@./bug_5.js:2:41
```

Created attachment 473307 [details]
poc-2.js

[Radar WebKit Bug Importer]

<rdar://problem/140651602>

[David Degazio]

As far as I can tell this is behaving correctly. We validate functions within a module in parallel, so the order in which they are validated is nondeterministic - this is permitted by the spec, which imposes no particular validation order, so long as a CompileError is raised on an invalid module at some point during validation (https://webassembly.github.io/spec/js-api/index.html#compile-a-webassembly-module). In the first PoC, while sequential validation would encounter the error in function index 1 first, it looks like another compiler thread starts validating function index 2 and encounters the validation error there first. You can observe that disabling parallel compilation (by passing --useConcurrentJIT=0 to the jsc shell) makes us report the error message from function index 1 consistently.

Closing with WONTFIX as this is expected behavior and correct according to the spec.

[Keith Miller]

I don't think this needs to be WONTFIX. I agree the spec says our behavior is valid but I don't think it's a lot of work to make consistent. We could just store the error message in the plan as a `std::pair<FunctionCodeIndex, String>` and just replace the existing error if the new index is less than the old one.

That said, I don't think this is particularly high impact so I'm not sure there's any rush to make this change.