1491322 - Crash [@ js::wasm::CodeRange::funcIndex] or Crash [@ JS::MutableHandle<JSFunction*>::MutableHandle] with wasm and Debugger

Status: RESOLVED DUPLICATE of bug 1486549

(Core :: JavaScript: WebAssembly, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision efccb758c78c (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe):

var evalInFrame = (function(global) {
    var dbgGlobal = newGlobal();
    var dbg = new dbgGlobal.Debugger();
    dbg.addDebuggee(global);
})(this);
const Module = WebAssembly.Module;
const Instance = WebAssembly.Instance;
var m = new Module(wasmTextToBinary(`(module
    (table 3 anyfunc)
    (import $foo "" "foo" (result i32))
    (import $bar "" "bar" (result i32))
    (func $baz (result i32) (i32.const 13))
    (elem (i32.const 0) $foo $bar $baz)
    (export "tbl" table)
)`));
var jsFun = () => 83;
var wasmFun = new Instance(
  new Module(
    wasmTextToBinary('(module (func (result i32) (i32.const 42)) (export "foo" 0))')
  )
).exports.foo;
var e1 = new Instance(m, {
    "": {
        foo: jsFun,
        bar: wasmFun
    }
}).exports;
var e2 = new Instance(m, {
    "": {
        foo: jsFun,
        bar: jsFun
    }
}).exports;
e2.tbl.get(0);


Backtrace:

received signal SIGSEGV, Segmentation fault.
js::wasm::CodeRange::funcIndex (this=this@entry=0x0) at js/src/wasm/WasmTypes.h:1623
#0  js::wasm::CodeRange::funcIndex (this=this@entry=0x0) at js/src/wasm/WasmTypes.h:1623
#1  0x00005555560944a6 in js::WasmTableObject::getImpl (cx=cx@entry=0x7ffff5f16000, args=...) at js/src/wasm/WasmJS.cpp:2156
#2  0x00005555560946cb in JS::CallNonGenericMethod<IsTable, js::WasmTableObject::getImpl> (args=..., cx=0x7ffff5f16000) at dist/include/js/CallNonGenericMethod.h:100
#3  js::WasmTableObject::get (cx=0x7ffff5f16000, argc=<optimized out>, vp=<optimized out>) at js/src/wasm/WasmJS.cpp:2168
#4  0x00005555557e0b85 in CallJSNative (cx=0x7ffff5f16000, native=0x555556094630 <js::WasmTableObject::get(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/Interpreter.cpp:460
[...]
#18 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:10713
rax	0x7fffffffca10	140737488341520
rbx	0x7ffff5f16000	140737319624704
rcx	0x7fffffffca60	140737488341600
rdx	0x7ffff4d00000	140737300660224
rsi	0x7ffff4d00000	140737300660224
rdi	0x0	0
rbp	0x7fffffffcaa0	140737488341664
rsp	0x7fffffffc9e8	140737488341480
r8	0x100000000	4294967296
r9	0x920	2336
r10	0xb	11
r11	0x7ffff5f30e00	140737319734784
r12	0x7fffffffca50	140737488341584
r13	0x7fffffffcab0	140737488341680
r14	0x7fffffffca10	140737488341520
r15	0x7fffffffca30	140737488341552
rip	0x555556006c20 <js::wasm::CodeRange::funcIndex() const>
=> 0x555556006c20 <js::wasm::CodeRange::funcIndex() const>:	cmpb   $0x5,0x18(%rdi)
   0x555556006c24 <js::wasm::CodeRange::funcIndex() const+4>:	jbe    0x555556006c50 <js::wasm::CodeRange::funcIndex() const+48>

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/9f7308df9f62
user:        Julian Seward
date:        Mon Sep 10 15:09:32 2018 +0200
summary:     Bug 1471500 - Complete initial implementation of the bulk-memory proposal.  Part 6 of 10.  r=bbouvier.

This iteration took 283.892 seconds to run.

Comment 2

[Luke Wagner [:luke]]

I haven't had a chance to look into the root cause, but this appears to be fixed by the second patch in bug 1486549.

Comment 3

[Julian Seward [:jseward]]

(In reply to Luke Wagner [:luke] from comment #2)

Superficially speaking, this happens because the following line
in WasmTableObject::getImpl makes |codeRange| be null, for the
test input.

  const CodeRange& codeRange = *instance.code().lookupFuncRange(elem.code);

Why though, I didn't chase.  Given that bug 1486549 appears to fix it, is
this worth chasing further?

Comment 4

[Luke Wagner [:luke]]

No, I think I know what the cause/fix is/was.  I'll definitely add this test case here with the patch in bug 1486549, though, so we would've caught this earlier.