1455603 - Assertion failure: !cx->suppressGC, at js/src/gc/PublicIterators.cpp:86 with wasm and Debugger

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

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

var lfModule = new WebAssembly.Module(wasmTextToBinary(`
    (module
        (import "global" "func" (result i32))
        (func (export "func_0") (result i32)
         call 0 ;; calls the import, which is func #0
        )
    )
`));
processModule(lfModule, `
  var g = newGlobal();
  var dbg = new Debugger(g);
  var target  = dbg.findScripts().filter(isWasm(g, isValidWasmURL, 2));
`);
function processModule(module, jscode) {
    imports = {}
    for (let descriptor of WebAssembly.Module.imports(module)) {
        imports[descriptor.module] = {}
        imports[descriptor.module][descriptor.name] = new Function("x", "y", "z", jscode);
        instance = new WebAssembly.Instance(module, imports);
        for (let descriptor of WebAssembly.Module.exports(module)) {
            print(instance.exports[descriptor.name]())
        }
    }
}


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0000000000f277c8 in js::IterateScripts (cx=0x7ffff5f15000, compartment=0x7ffff5f4f800, data=data@entry=0x7fffffffb620, scriptCallback=scriptCallback@entry=0xb262b0 <js::Debugger::ScriptQuery::considerScript(JSRuntime*, void*, JSScript*)>) at js/src/gc/PublicIterators.cpp:86
#0  0x0000000000f277c8 in js::IterateScripts (cx=0x7ffff5f15000, compartment=0x7ffff5f4f800, data=data@entry=0x7fffffffb620, scriptCallback=scriptCallback@entry=0xb262b0 <js::Debugger::ScriptQuery::considerScript(JSRuntime*, void*, JSScript*)>) at js/src/gc/PublicIterators.cpp:86
#1  0x0000000000b295c5 in js::Debugger::ScriptQuery::findScripts (this=this@entry=0x7fffffffb620) at js/src/vm/Debugger.cpp:4416
#2  0x0000000000b111c6 in js::Debugger::findScripts (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>) at js/src/vm/Debugger.cpp:4718
#3  0x00000000005b2e4e in js::CallJSNative (cx=0x7ffff5f15000, native=0xb10c90 <js::Debugger::findScripts(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/JSContext-inl.h:280
#4  0x00000000005a77af in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f15000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:467
#5  0x00000000005a7b8d in InternalCall (cx=0x7ffff5f15000, args=...) at js/src/vm/Interpreter.cpp:516
#6  0x0000000000599fc1 in js::CallFromStack (args=..., cx=<optimized out>) at js/src/vm/Interpreter.cpp:522
#7  Interpret (cx=0x7ffff5f15000, state=...) at js/src/vm/Interpreter.cpp:3084
#8  0x00000000005a726d in js::RunScript (cx=0x7ffff5f15000, state=...) at js/src/vm/Interpreter.cpp:417
#9  0x00000000005a7877 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f15000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:489
#10 0x00000000005a7b8d in InternalCall (cx=0x7ffff5f15000, args=...) at js/src/vm/Interpreter.cpp:516
#11 0x00000000005a7d10 in js::Call (cx=<optimized out>, fval=..., fval@entry=..., thisv=..., thisv@entry=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:535
#12 0x0000000000dde0ad in js::wasm::Instance::callImport (this=this@entry=0x7ffff49fb5f0, cx=<optimized out>, cx@entry=0x7ffff5f15000, funcImportIndex=funcImportIndex@entry=0, argc=argc@entry=0, argv=argv@entry=0x7fffffffc500, rval=..., rval@entry=...) at js/src/wasm/WasmInstance.cpp:156
#13 0x0000000000ddeba4 in js::wasm::Instance::callImport_i32 (instance=0x7ffff49fb5f0, funcImportIndex=0, argc=0, argv=0x7fffffffc500) at js/src/wasm/WasmInstance.cpp:252
#14 0x00002c895f29b0fc in ?? ()
[...]
#20 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff5f15000	140737319620608
rcx	0x7ffff6c282ad	140737333330605
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffffb4c0	140737488336064
rsp	0x7fffffffb310	140737488335632
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4780	140737354024832
r10	0x58	88
r11	0x7ffff6b9e7a0	140737332766624
r12	0x7ffff5f4f800	140737319860224
r13	0x7fffffffb530	140737488336176
r14	0x7fffffffb620	140737488336416
r15	0x7ffff49ec000	140737297432576
rip	0xf277c8 <js::IterateScripts(JSContext*, JSCompartment*, void*, void (*)(JSRuntime*, void*, JSScript*))+984>
=> 0xf277c8 <js::IterateScripts(JSContext*, JSCompartment*, void*, void (*)(JSRuntime*, void*, JSScript*))+984>:	movl   $0x0,0x0
   0xf277d3 <js::IterateScripts(JSContext*, JSCompartment*, void*, void (*)(JSRuntime*, void*, JSScript*))+995>:	ud2

Comment 1

[Fuzzing Team]

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

Comment 2

[Lars T Hansen [:lth]]

I guess we knew we might run into some of these issues.  If it's only the debugger that's affected we probably shouldn't panic, but worth tracking these.

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

This assertion was created for bug 1325050, but I think now we're getting rid of all the multithreading runtime machinery, and  there's only one user of IterateScripts left, which could even be inlined into vm/Debugger.cpp instead, without the callback argument. (it's also used in a test that doesn't seem to GC, but we could remove this) Mrgiggles says that the only provided callback, Debugger::ScriptQuery::considerScript cannot GC, so we could probably remove this assertion. Jon, thoughts?

Comment 4

[Jon Coppeard (:jonco)]

(In reply to Benjamin Bouvier [:bbouvier] from comment #3)
> This assertion was created for bug 1325050

No, it was created by bug 1239813.  It's there to make sure that we actually do evict the nursery when we call this function.  And *that* was added in bug 945250.  See the latter for a rationale.

It's possible that this is unnecessary since the other patch in bug 1239813 landed, but I'm not 100% convinced of that (and it will take a while to study what's going on here).

Comment 5

[Jon Coppeard (:jonco)]

This is only an issue when we're suppressing GC for wasm.  How about we disable the debugger findScripts API when we're in this mode?

Comment 6

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: disable-debugger-findscripts.patch

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1781bcae61d0
Disable the Debugger.findScripts API when wasm GC is active; r=jonco

Comment 8

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/1781bcae61d0