1618495 - Crash in debugger of WebAssembly: unsupported global variable type

Status: RESOLVED FIXED

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

Description

[Volker Berlin]

Attachment: FF-Crash-Report.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

I use the FF Nightly from today, 75.0a1 (2020-02-26) (64-Bit).

In the attachments there are screenshots to visualize the follow steps. There are also all files that are involved.

1.) Open the sample start page in the nightly FF browser. I use the URL http://localhost/test/HelloWorld.html
2.) Open the debugger and set a breakpoint in the file HelloWorld.wasm.js:9 in the function set_anyref.
3.) Reload the page.
4.) Click in the stacktrace the first wasm line (HelloWorld.wasm:1364)
5.) Some seconds later -> Crash

Comment 1

[Lars T Hansen [:lth]]

I can reproduce this on Linux using the provided steps (Fedora 30 on x64).

Comment 2

[Lars T Hansen [:lth]]

https://crash-stats.mozilla.org/report/index/40e93717-84e0-48f9-9474-32d170200227

Comment 3

[Lars T Hansen [:lth]]

That appears to be a MOZ_CRASH, it's a getGlobal on an unsupported type. Might we guess this would be a reference type? wat2wasm crashes on it, which is no fun at all.

Comment 4

[Lars T Hansen [:lth]]

Jan, can you open this up? MOZ_CRASH is not s-s.

Comment 5

[Jan de Mooij [:jandem]]

(In reply to Lars T Hansen [:lth] from comment #4)

Jan, can you open this up? MOZ_CRASH is not s-s.

I can only change the JS security group flag, not the core-security one.

Comment 6

[Lars T Hansen [:lth]]

I'll add a suitable short-term fix and maybe let Yury do something smarter in the long term.

Comment 7

[Lars T Hansen [:lth]]

Attachment: Bug 1618495 - Handle reference types in wasm debugger. r?yury

For reference types, return 0 when they are read from wasm globals.
This is an adequate stopgap solution. See comment in the code for
ideas about better solutions.

Comment 8

[Lars T Hansen [:lth]]

Yury, I'm unable to test this fix because when I build Nightly locally it appears to come without the debugging tools that I need (starting with output like this:

console.error: (new Error("Unexpected type", "resource://devtools/client/shared/vendor/WasmDis.js", 36))
console.warn: "Action loadSourceText had an exception:" (new Error("Unexpected type", "resource://devtools/client/shared/vendor/WasmDis.js", 36))

Can you look at the patch, maybe try it locally to see if it fixes the problem? Or let me know how I install enough code to run the debugger in a Nightly build without the errors above...

Comment 9

[Yury Delendik (:yury)]

(In reply to Lars T Hansen [:lth] from comment #8)

Yury, I'm unable to test this fix because when I build Nightly locally it appears to come without the debugging tools that I need

I working on updating wasm display for FF DevTools in bug 1619737 -- that shall take care of that

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/614a2f1056b2
Handle reference types in wasm debugger.  r=yury

Comment 11

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/614a2f1056b2

Comment 12

[Volker Berlin]

I test it with the version from today 75.0a1 (2020-03-06) (64-Bit)

It work better but I can reproduce the crash with the sample.

1.) Open the sample start page in the nightly FF browser. I use the URL http://localhost/test/HelloWorld.html
2.) Open the debugger and set a breakpoint in the file HelloWorld.wasm.js:9 in the function set_anyref.
3.) Reload the page.
4.) Click "Step Return" 4 times until we receive the stacktrace position of the first wasm line (HelloWorld.wasm:1365)
5.) Some seconds later -> Crash

Comment 13

[Lars T Hansen [:lth]]

I can confirm the crash on linux64 (it's also in the debugger) but the underlying cause is something different, so far as I can tell. I'm going to re-close this bug as fixed and open another one. Volker, I'll cc you on that bug too.

Comment 14

[Lars T Hansen [:lth]]

re-flagging this as fixed as the new issue was transfered to bug 1620748.