1877358 - AddressSanitizer: SEGV on unknown address 0x70007fff8003 when WASM exceptions are disabled

Status: RESOLVED FIXED

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

Description

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

Attachment: debug stack

(function (s, foreign, h) {
  "use asm";
  var g = foreign.m;
  function f() {
    g()
  }
  return f;
})(
  this,
  { m: (function(){x}) }
)();

AddressSanitizer:DEADLYSIGNAL
=================================================================
==15424==ERROR: AddressSanitizer: SEGV on unknown address 0x70007fff8003 (pc 0x558f05b9c9df bp 0x7ffc8ed74510 sp 0x7ffc8ed74400 T0)
==15424==The signal is caused by a READ memory access.
    #0 0x558f05b9c9df in JS::Value::toPrivate() const /home/skygentoo/shell-cache/js-64-asan-linux-x86_64-2eb7051ff4ed/objdir-js/dist/include/js/Value.h:1055:46
    #1 0x558f05b9c9df in js::WasmTagObject::tagType() const /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmJS.cpp:3587:50
    #2 0x558f05b9c9df in js::WasmExceptionObject::create(JSContext*, JS::Handle<js::WasmTagObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>) /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmJS.cpp:3797:33
    #3 0x558f05bf705a in js::WasmExceptionObject::wrapJSValue(JSContext*, JS::Handle<JS::Value>) /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmJS.cpp:3834:7
    #4 0x558f05ad815c in GetOrWrapWasmException(js::jit::JitActivation*, JSContext*) /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmBuiltins.cpp:619:17
    #5 0x558f05ad815c in js::wasm::HandleThrow(JSContext*, js::wasm::WasmFrameIter&, js::jit::ResumeFromException*) /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmBuiltins.cpp:668:40
    #6 0x558f05ada40f in WasmHandleThrow(js::jit::ResumeFromException*) /home/skygentoo/trees/mozilla-central/js/src/wasm/WasmBuiltins.cpp:780:3
    #7 0x368e2db17559  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/skygentoo/shell-cache/js-64-asan-linux-x86_64-2eb7051ff4ed/objdir-js/dist/include/js/Value.h:1055:46 in JS::Value::toPrivate() const
==15424==ABORTING

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/aa4e04a7fa90
user:        Ryan Hunt
date:        Thu Jan 25 13:08:36 2024 +0000
summary:     Bug 1873776 - wasm: Wrap thrown non-WebAssembly.Exception values in a WebAssembly.Exception when unwinding. r=yury

Run with --fuzzing-safe --no-threads --ion-eager --no-wasm-exceptions, compile with AR=ar sh ../configure --enable-address-sanitizer --enable-fuzzing --disable-jemalloc --disable-stdcxx-compat --without-sysroot --with-ccache --enable-nspr-build --enable-ctypes --enable-gczeal --enable-rust-simd --disable-tests, tested on m-c rev 2eb7051ff4ed.

Ryan, is bug 1873776 a likely regressor? Setting s-s to be safe.

Comment 1

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

Set release status flags based on info from the regressing bug 1873776

Comment 2

[Ryan Hunt [:rhunt]]

I can reproduce the crash here. The issue is caused by us only initializing a value when wasm exceptions are enabled that is also used when wasm exceptions are disabled. Fix should be pretty simple. This can only happen if wasm exceptions are disabled, which is a non-standard configuration, so no users should be affected.

Comment 3

[Ryan Hunt [:rhunt]]

Attachment: Bug 1877358 - wasm: Create wrapper tag unconditionally. r?yury

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/122b56d468fe
wasm: Create wrapper tag unconditionally. r=yury

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/122b56d468fe

Comment 6

[Daniel Veditz [:dveditz]]

This can only happen if wasm exceptions are disabled, which is a non-standard configuration, so no users should be affected.

Why did we implement a way to disable these? Is it "uncommon", or impossible to use in Firefox? Not sure how far to interpret "non-standard". Do folks use this engine in other products with exceptions disabled?

Comment 7

[Ryan Hunt [:rhunt]]

(In reply to Daniel Veditz [:dveditz] from comment #6)

This can only happen if wasm exceptions are disabled, which is a non-standard configuration, so no users should be affected.

Why did we implement a way to disable these? Is it "uncommon", or impossible to use in Firefox? Not sure how far to interpret "non-standard". Do folks use this engine in other products with exceptions disabled?

We develop all new wasm features behind a pref, then ship it in Firefox by enabling the pref. The pref remains for a while before we remove it, just to give the feature time to stabilize (I'm planning on removing two prefs that have been stable for a while). To disable exceptions, a user would have to go to about:config and disable javascript.options.wasm_exceptions, so not impossible just very unlikely as we don't really advertise the prefs.

I don't know of any other products that use the wasm engine in SM, but if there are any I would be surprised if they chose to disable the 'exceptions' feature.

Comment 8

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

Set release status flags based on info from the regressing bug 1873776