1628426 - Assertion failure: results.length() == 1 (multi-value return unimplemented), at wasm/WasmTypes.cpp:728

Status: VERIFIED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20200408-6663d3dc883b (build with --enable-debug, run with --fuzzing-safe --no-threads test.js):

See attachment.

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x00005555569152d0 in js::wasm::DebugFrame::updateReturnJSValue() ()
#0  0x00005555569152d0 in js::wasm::DebugFrame::updateReturnJSValue() ()
#1  0x00005555567ea7a7 in WasmHandleDebugTrap() ()
#2  0x00001bb999206666 in ?? ()
#3  0x00007fffffffb2e0 in ?? ()
#4  0x00005555567ea745 in WasmHandleDebugTrap() ()
#5  0x00007ffff5bfc380 in ?? ()
[...]
#10 0x0000000000000000 in ?? ()
rax	0x555556fbd3dc	93825019925468
rbx	0x7fffffffb478	140737488335992
rcx	0x555557f46850	93825036216400
rdx	0x0	0
rsi	0x7ffff6efd770	140737336301424
rdi	0x7ffff6efc540	140737336296768
rbp	0x7fffffffb270	140737488335472
rsp	0x7fffffffb1e0	140737488335328
r8	0x7ffff6efd770	140737336301424
r9	0x7ffff7f9bd00	140737353727232
r10	0x58	88
r11	0x7ffff6ba47a0	140737332791200
r12	0x7fffffffb478	140737488335992
r13	0x7ffff5e26220	140737318642208
r14	0x7ffff5e27000	140737318645760
r15	0x7ffff5e7a6a0	140737318987424
rip	0x5555569152d0 <js::wasm::DebugFrame::updateReturnJSValue()+768>
=> 0x5555569152d0 <_ZN2js4wasm10DebugFrame19updateReturnJSValueEv+768>:	movl   $0x2d8,0x0
   0x5555569152db <_ZN2js4wasm10DebugFrame19updateReturnJSValueEv+779>:	callq  0x555555814706 <abort>

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Andy Wingo [:wingo]]

OK so this is where the debugger can inspect the JS return value of a frame. The raw value is set by the baseline compiler at a well-known offset in the frame. However for multiple return values we also need to store the pointer to the stack results also in the debugframe, as the debugger won't know where it is otherwise. I think we can probably implement this by just adding a word to the DebugFrame in the baseline prologue, initialized to the stack result area pointer if the function returns multiple values. We can pass a JSContext* to updateReturnJSValue so that it can allocate to make the JS result, if needed.

Comment 3

[Andy Wingo [:wingo]]

One-file reproducer:

var g20 = newGlobal({
    newCompartment: true
});
g20.parent = this;
g20.eval("Debugger(parent).onEnterFrame = function() {};");

let bytes = wasmTextToBinary(`
   (module
     (func $dup (param i32) (result i32 i32)
       (local.get 0)
       (local.get 0))
     (func $main (export "main") (param i32 i32) (result i32)
       (local.get 1)
       (call $dup)
       (drop)))`);

let instance = new WebAssembly.Instance(new WebAssembly.Module(bytes));

instance.exports.main(0, 1);

Comment 4

[Andy Wingo [:wingo]]

Attachment: Bug 1628426 - Support access to multi-value WebAssembly results in DebugFrame

This commit firstly moves ResultType and BlockType from WasmOpIter.h to
WasmTypes.h. Many parts of the WebAssembly implementation find
themselves dealing in ResultType so it's natural to define these data
types in a more central place.

Then we add a field to DebugFrame, for the stack results area. This
field is initialized in the baseline compiler prologue, in debug mode.

Finally, we now expose the guts of the ToJSValue code in WasmInstance to
allow the debug trap to synthesize a JS value for a wasm result, even
for multiple value results.

Depends on D70484

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7f852ba3cd1
Support access to multi-value WebAssembly results in DebugFrame r=lth

Comment 6

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/e7f852ba3cd1

Comment 7

[Jason Kratzer [:jkratzer]]

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20200423095248-47426d145e24.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.