-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stack traces in streaming WASM modules should show the module URL #12151
Comments
andreubotella
pushed a commit
to andreubotella/rusty_v8
that referenced
this issue
Sep 22, 2021
andreubotella
pushed a commit
to andreubotella/rusty_v8
that referenced
this issue
Sep 22, 2021
ry
pushed a commit
to denoland/rusty_v8
that referenced
this issue
Sep 22, 2021
andreubotella
pushed a commit
to andreubotella/deno
that referenced
this issue
Sep 29, 2021
WebAssembly modules compiled through `WebAssembly.compile()` and similar non-streaming APIs don't have a URL associated to them, because they have been compiled from a buffer source. In stack traces, V8 will use a URL such as `wasm://wasm/d1c677ea`, with a hash of the module. However, wasm modules compiled through streaming APIs, like `WebAssembly.compileStreaming()`, do have a known URL, which can be obtained from the `Response` object passed into the streaming APIs. And as per the developer-facing display conventions in the WebAssembly Web API spec, this URL should be used in stack traces. This change implements that. Closes denoland#12151.
andreubotella
pushed a commit
to andreubotella/deno
that referenced
this issue
Oct 5, 2021
WebAssembly modules compiled through `WebAssembly.compile()` and similar non-streaming APIs don't have a URL associated to them, because they have been compiled from a buffer source. In stack traces, V8 will use a URL such as `wasm://wasm/d1c677ea`, with a hash of the module. However, wasm modules compiled through streaming APIs, like `WebAssembly.compileStreaming()`, do have a known URL, which can be obtained from the `Response` object passed into the streaming APIs. And as per the developer-facing display conventions in the WebAssembly Web API spec, this URL should be used in stack traces. This change implements that. Closes denoland#12151.
andreubotella
pushed a commit
to andreubotella/deno
that referenced
this issue
Oct 7, 2021
WebAssembly modules compiled through `WebAssembly.compile()` and similar non-streaming APIs don't have a URL associated to them, because they have been compiled from a buffer source. In stack traces, V8 will use a URL such as `wasm://wasm/d1c677ea`, with a hash of the module. However, wasm modules compiled through streaming APIs, like `WebAssembly.compileStreaming()`, do have a known URL, which can be obtained from the `Response` object passed into the streaming APIs. And as per the developer-facing display conventions in the WebAssembly Web API spec, this URL should be used in stack traces. This change implements that. Closes denoland#12151.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The WebAssembly Web API spec has a non-normative section about how WASM stack traces should be displayed. Some of the things it suggests –like reporting the line in JS in which a WASM module was instantiated much like with
eval
calls– don't seem to be supported by V8. But it also suggests that, for WASM modules compiled withResponse
-based APIs (that is,WebAssembly.compileStreaming()
andWebAssembly.instantiateStreaming()
), the stack trace should show the URL of the WASM module.To show that V8 does support this but Deno doesn't, these are the results of my tests (https:/andreubotella/wasm-stack-trace-test) in Chrome and in Deno:
(Note that Chrome seems to cache the URL of WASM modules, such that if you navigate from syncTest.html to asyncTest.html, you'd get the hash rather than the URL, and vice versa. The screenshots above were taken on new tabs.)
I believe this would be easy to hook up once
v8::WasmStreaming
'sSetUrl
method is exposed in rusty_v8.The text was updated successfully, but these errors were encountered: