1678757 - WebAssembly (Wasm) error messages state 'undefined' when earlier versions gave more detail

Status: RESOLVED FIXED

(DevTools :: Object Inspector, defect)

Description

[greens]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

All my testing in on Firefox 83 within Ubuntu.

Here is a way you can trigger an error in Wasm - this is JavaScript code you can run in an HTML file. I'm offering two versions - one without an error and one with an error. The one with an error gives the vague error message.

Leave the Firefox Web Console open to see the place where these errors should show. That's how you'll receive the 'undefined' error. Basically, anywhere I get a Wasm error, it's always the generic version and never breaks down the issue while previous Firefox versions gave much more information.

// This code does not trigger an error because two constants are on stack prior to use of i32.add instruction:
// HEX prior to integer conversion
// 00,61,73,6d,01,00,00,00,01,05,01,60,00,01,7f,03,02,01,00,0a,09,01,07,00,41,0a,41,0a,6a,0b
wa_int_array1=[0,97,115,109,1,0,0,0,1,5,1,96,0,1,127,3,2,1,0,10,9,1,7,0,65,10,65,10,106,11];
wa_content1=new Uint8Array(wa_int_array1);
wa_promise1=WebAssembly.compile(wa_content1);
wa_promise1.then(wa_module1=> {
// Module without error
})
// See Breakdown 1 below to see more detail

// This code should trigger an error because
// ... there was only 1 constant value added to stack
// ... then i32.add was applied
// ... but you can't add 1 number to nothing since i32.add requires 2 values on the stack
// Was expecting an error like this from FF console
// ... CompileError: wasm validation error: at offset 26: popping value from empty stack
// but received this error instead
// ... Uncaught (in promise) Error: undefined
// HEX prior to integer conversion
// 00,61,73,6d,01,00,00,00,01,05,01,60,00,01,7f,03,02,01,00,0a,07,01,05,00,41,0a,6a,0b
wa_int_array2=[0,97,115,109,1,0,0,0,1,5,1,96,0,1,127,3,2,1,0,10,7,1,5,0,65,10,106,11];
wa_content2=new Uint8Array(wa_int_array2);
wa_promise2=WebAssembly.compile(wa_content2);
wa_promise2.then(wa_module2=> {
// Module with error
})
// See Breakdown 2 below to see more detail

/*

BREAKDOWN 1:

Breakdown of wa_int_array1 array elements as WAT

(module
(func $func0 (result i32)
i32.const 10
i32.const 10
i32.add
)
)

Breakdown of wa_int_array1 array elements
AS
byte number - then hex value - then comments

Preamble section, 0-7 bytes
b:0 00 ~
b:1 61 ~
b:2 73 ~
b:3 6d ::magic number
b:4 01 ~
b:5 00 ~
b:6 00 ~
b:7 00 ::version

Type Module, 8-14 bytes
b:8 01 ::id/section
b:9 05 ::payload_len
b:10 01 ::count
b:11 60 ::form/type constructor func
b:12 00 ::param_count
b:13 01 ::return_count
b:14 7f ::return_type

Function Module, 15-18 bytes
b:15 03 ::id/section
b:16 02 ::payload_len
b:17 01 ::count
b:18 00 ::type m. index

Code Module, 19-29 bytes
b:19 0a ::id/section
b:20 09 ::payload_len
b:21 01 ::count
b:22 07 ::body_size
b:23 00 ::local_count
b:24 41 ::i32.const - add const to stack - opcode 1/2
b:25 0a ::i32.const value - add const to stack - value 2/2
b:26 41 ::i32.const - add const to stack - opcode 1/2
b:27 0a ::i32.const value - add const to stack - value 2/2
b:28 6a ::instr - ibinop, i32.add - add both constants together - opcode 1/1
b:29 0b ::end
/
/

BREAKDOWN 2:

Breakdown of wa_int_array2 array elements as WAT

(module
(func $func0 (result i32)
i32.const 10
i32.add
)
)

Breakdown of wa_int_array2 array elements
AS
byte number - then hex value - then comments

Preamble section, 0-7 bytes
b:0 00 ~
b:1 61 ~
b:2 73 ~
b:3 6d ::magic number
b:4 01 ~
b:5 00 ~
b:6 00 ~
b:7 00 ::version

Type Module, 8-14 bytes
b:8 01 ::id/section
b:9 05 ::payload_len
b:10 01 ::count
b:11 60 ::form/type constructor func
b:12 00 ::param_count
b:13 01 ::return_count
b:14 7f ::return_type

Function Module, 15-18 bytes
b:15 03 ::id/section
b:16 02 ::payload_len
b:17 01 ::count
b:18 00 ::type m. index

Code Module, 19-27 bytes
b:19 0a ::id/section
b:20 07 ::payload_len
b:21 01 ::count
b:22 05 ::body_size
b:23 00 ::local_count
b:24 41 ::i32.const
b:25 0a ::i32.const value
b:26 6a ::instr - ibinop, i32.add - add both constants together - opcode 1/1
b:27 0b ::end
*/

Actual results:

The same error message is received in the 'console' no matter what the error is when building Wasm code.

Error Message:
Uncaught (in promise) Error: undefined

Expected results:

I used to receive all types of Wasm errors (and was recording them), now only that - undefined - vague error displays - no matter the issue.

These are examples from different Firefox versions. These were quite helpful to debug Wasm code.

Firefox 70.0.1
CompileError: wasm validation error: at offset 824: popping value from empty stack

Firefox 80
Uncaught (in promise) CompileError: wasm validation error: at offset 47: initializer expression must reference a global immutable import

Firefox 80
Uncaught (in promise) LinkError: imported Memory with incompatible size

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Lars T Hansen [:lth]]

The shell error message from current code:

Unhandled rejection: (new CompileError("wasm validation error: at offset 26: popping value from empty stack", "/home/lhansen/moz/bad.js line 3 > WebAssembly.compile", 3))
(no stack trace available)

Comment 3

[Lars T Hansen [:lth]]

Yeah, this is not good. I'm seeing the same in Nightly 85 on Linux and the Fedora-provided FF83.

Comment 4

[Lars T Hansen [:lth]]

The correct error is printed in the shell window when running a local build. And stepping through it in the debugger, the correct error is passed up the stack quite a ways. To me, it looks like the correct error object for the promise rejection is being constructed by the JS engine, but that it is being lost (or parts of it are being ignored) somewhere on the way to the console when the promise is being signaled as rejected.

(Another difference here is that there's no stack trace information, which is a change from FF83.)

The next step here would be to break in PromiseReactionJob and step in from there, I think. No time today.

Comment 5

[Tom S. (please needinfo tschuster)]

I would just use mozregression to figure out what regressed this.

Comment 6

[Lars T Hansen [:lth]]

Attachment: Test case, can be loaded from a file: URL

Comment 7

[Lars T Hansen [:lth]]

(In reply to Tom Schuster [:evilpie] from comment #5)

I would just use mozregression to figure out what regressed this.

I guess. Never got mozregression to do anything for me :-/

Comment 8

[Lars T Hansen [:lth]]

I'm inclined to worry about this, though it is perhaps a little old:

changeset:   591723:84c55ea8397f
user:        Nicolas Chevobbe <[e-mail]>
date:        Mon May 11 10:38:57 2020 +0000
summary:     Bug 1595046 - Display thrown object as inspectable elements. r=Honza,perftest-reviewers,davehunt.

Comment 9

[Tom S. (please needinfo tschuster)]

Interesting I got:
4:45.39 INFO: Last good revision: 932240e49142e17bdacd2bb6a12afa92f52d2b52
4:45.39 INFO: First bad revision: eba7e3ce93822075543bcc764cef7dbc8e9fc5f1
4:45.39 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=932240e49142e17bdacd2bb6a12afa92f52d2b52&tochange=eba7e3ce93822075543bcc764cef7dbc8e9fc5f1

I think the relevant change is bug 1651402 and bug 1650776. Presumably CompileError is somehow different from other Error objects.
Bug 1595046 just changed the error message maybe?

Comment 10

[Lars T Hansen [:lth]]

Possibly, possibly... I'm not normally in this part of the code.

Bug 1595046 mucked around with the error display and how error objects are being unpackaged, which is why I suspected it, but I have not gone deep into it.

Comment 11

[Lars T Hansen [:lth]]

Wasm errors are ErrorObject instances created through ErrorObject::create, so at least from a superficial point of view they're not different from other error objects and should respond to isError just fine.

Comment 12

[Tom S. (please needinfo tschuster)]

I suspect this is a devtools problem, but I am not quite sure where message comes from: https://searchfox.org/mozilla-central/source/devtools/client/shared/components/reps/reps/error.js#102

Comment 13

[Nicolas Chevobbe [:nchevobbe]]

Attachment: image.png

Hello there, I do think it's a devtools issue indeed, and I think I found the origin of it.

Is the following message what you'd expect?

Uncaught (in promise) CompileError: wasm validation error: at offset 26: popping value from empty stack debugger

If so, I'll put up a patch to fix this, alongside with a test to make sure we don't regress.

Comment 14

[Lars T Hansen [:lth]]

That is indeed the message we expect to see!

Comment 15

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1678757 - [devtools] Add missing errors in Error previewer. r=bomsy.

We weren't handling the error exception object in the Error previewer,
and as a result we'd show an undefined grip in the console, instead of
a proper error message.
This is fixed by handling CompileError in Error object previewer, like
the other kinds of errors.
A test is added to ensure we don't regress this.

Comment 16

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

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/85d1fafd696a
[devtools] Add missing errors in Error previewer. r=bomsy.

Comment 18

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/85d1fafd696a