1507314 - Crash [@ js::wasm::Module::deserialize] or Assertion failure: EqualContainers(currentBuildId, deserializedBuildId), at js/src/wasm/WasmModule.cpp:263

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The following testcase crashes on mozilla-central revision b0b856065d5b (build with --build-with-clang --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager --no-sse4):

// Adapted from randomly chosen test: js/src/jit-test/tests/wasm/caching.js
wasmCompileInSeparateProcess(wasmTextToBinary(`
    (module
        (func $test
            (param i64)
            (result f64)
            get_local0 f64.convert_u/i64
        )
        (func
            (result i32)
            i64.const1
            call $test
            f64.const1
            f64.eq
        )
    )
`))();

Backtrace:

# Child-SP          RetAddr           Call Site
00 000000a1`d5bfd590 00007ff7`65e76a7c js_dbg_64_clang_windows_b0b856065d5b!js::wasm::Module::deserialize+0xfc8 [c:\Users\fuzz1win\trees\mozilla-central\js\src\wasm\WasmModule.cpp @ 263]
01 000000a1`d5bfe120 00007ff7`655b49e6 js_dbg_64_clang_windows_b0b856065d5b!js::wasm::DeserializeModule+0x3c [c:\Users\fuzz1win\trees\mozilla-central\js\src\wasm\WasmJS.cpp @ 480]
02 000000a1`d5bfe170 00007ff7`6562136b js_dbg_64_clang_windows_b0b856065d5b!WasmCompileInSeparateProcess+0x226 [c:\Users\fuzz1win\trees\mozilla-central\js\src\shell\js.cpp @ 6173]
03 000000a1`d5bfe2c0 00007ff7`65620dae js_dbg_64_clang_windows_b0b856065d5b!CallJSNative+0x11b [c:\Users\fuzz1win\trees\mozilla-central\js\src\vm\Interpreter.cpp @ 468]
04 000000a1`d5bfe330 00007ff7`65621c94 js_dbg_64_clang_windows_b0b856065d5b!js::InternalCallOrConstruct+0x38e [c:\Users\fuzz1win\trees\mozilla-central\js\src\vm\Interpreter.cpp @ 560]
05 000000a1`d5bfe410 00007ff7`660c185e js_dbg_64_clang_windows_b0b856065d5b!InternalCall+0x104 [c:\Users\fuzz1win\trees\mozilla-central\js\src\vm\Interpreter.cpp @ 614]
/snip

For detailed crash information, see attachment.

This crashes 64-bit opt builds [@ js::wasm::Module::deserialize] and seems Windows-only. Setting s-s as I don't know how bad this is.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Detailed Crash Information

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/6e842238034c
user:        Luke Wagner
date:        Tue Nov 06 13:09:04 2018 -0600
summary:     Bug 1500203 - Baldr: add wasmCompileInSeparateProcess() shell testing function and tests using it (r=bbouvier)

Luke, is bug 1500203 a likely regressor?

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Opt shell stack

Comment 4

[Luke Wagner [:luke]]

(not s-s because this shell function is testing a feature that hasn't shipped)

The assert is probably about a failure to correctly propagate that "--no-see4".

Comment 5

[Luke Wagner [:luke]]

Oh yeah, Windows-only; this is surely the argument-mangling for spawning the child process, and thus a test-only failure.

Comment 6

[Luke Wagner [:luke]]

Attachment: propagated-flags-first

Oh, right, option parsing stops at the first non-"--"-prefixed flag, so the propagated flags have to go first.

Comment 7

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 8

[Benjamin Bouvier [:bbouvier] (inactive)]

Comment on attachment 9025409 [details] [diff] [review]
propagated-flags-first

Review of attachment 9025409 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

::: js/src/shell/js.cpp
@@ +6173,5 @@
> +    }
> +    MOZ_RELEASE_ASSERT(flagIndex < sArgc);
> +
> +    int fdsIndex = flagIndex + 1;
> +    MOZ_RELEASE_ASSERT(fdsIndex == sArgc - 4);

fdsIndex <= sArgc - 4, in case new parameters are added in the future? (Also I find it reads better as fdsIndex + 4 <= sArgc, considering the accesses below)

Comment 9

[Luke Wagner [:luke]]

(In reply to Benjamin Bouvier [:bbouvier] from comment #8)
> > +    int fdsIndex = flagIndex + 1;
> > +    MOZ_RELEASE_ASSERT(fdsIndex == sArgc - 4);
> 
> fdsIndex <= sArgc - 4, in case new parameters are added in the future? (Also
> I find it reads better as fdsIndex + 4 <= sArgc, considering the accesses
> below)

My reasoning here is that once the option parser sees the non-"--"-prefixed fd numbers, it stops parsing, so there shouldn't be anything after the fd numbers.  (Indeed, that's the source of this bug.)  Thus, there really shouldn't be anything after the fd numbers.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7154eb3601f3
Baldr: correctly propagate shell flags to nested testig process on Windows (r=bbouvier)

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7154eb3601f3