Skip to content
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

debugging #307

Open
devsnek opened this issue Jun 12, 2024 · 4 comments
Open

debugging #307

devsnek opened this issue Jun 12, 2024 · 4 comments

Comments

@devsnek
Copy link
Member

devsnek commented Jun 12, 2024

(based on this issue: denoland/deno#22861)

What is a human supposed to do with a WebAssembly.Exception instance? There seems to be no stack trace captured during wasm execution and any data this object does contain is not enumerable, so there is nothing one can do to extract any useful information from it?

If I'm wrong or there are future plans or I'm generally being dumb please let me know...

@dschuff
Copy link
Member

dschuff commented Jun 12, 2024

No, you aren't wrong or being dumb; when an exception is created implicitly via the wasm throw instruction, there is no stack trace captured. This is to keep exception creation/throwing as fast as possible (some use cases want to use exceptions as a more general control-flow mechanism rather than having them be truly exceptional, and having to do a stack walk on every throw is problematic). But that means when the exception propagates out to JS there isn't the usual stack trace that you'd expect on an Error object. It is possible to create an exception that has a stack trace via the JS API though. You can call out from wasm to JS and run something like the following:

let e = new WebAssembly.Exception(MyExceptionTag, [payload], {traceStack: true});
e.message = "An exception message";
throw e;

Where MyExceptionTag is exported from the wasm module. This allows catching these exceptions (and rethrowing and extracting the payload) in wasm the same way you'd catch exceptions thrown with the throw instruction (using the same tag). And when the exception propagates out from wasm to JS the WebAssembly.Exception that comes out will have the message and stack trace. It's still observably different from an instance of Error but it has the fields that you want. This is a bit of a compromise but works well, and it's what we do in emscripten.

Of course if you're calling out to JS, it's also possible to just actually create and throw real Error objects. You can rethrow them in wasm, and if you import the JS exception tag into your module, you can catch them by tag and extract the Error object as the payload (it will appear as an externref).

@devsnek
Copy link
Member Author

devsnek commented Jun 12, 2024

hmm this generally makes sense to me, though the problem I encountered is a bit different. I did not author the wasm, and the person who did doesn't understand why it created this exception either (interestingly, I think it was created using emscripten as well? But it doesn't export any tags or anything that JS could use to inspect the exception. I'm not super familiar with the details of dart to wasm compilation though, this was just something a user reported to me)

I get that there's a conceptual boundary formed by tags as capabilities, but I feel like the API is lacking in that there's no way to inspect these at all. Do I really need to like mod v8 or something to debug a wasm blob that is misbehaving?

@dschuff
Copy link
Member

dschuff commented Jun 12, 2024

If this is Dart code, then it probably wasn't created by Emscripten; dart has a different compiler. (I might be able to find out how that compiler uses exceptions though).
Is this situation materially different from JS code that throws something other than an Error object? e.g. don't you also get an exception without a stack trace in that case?

@devsnek
Copy link
Member Author

devsnek commented Jun 13, 2024

(I might be able to find out how that compiler uses exceptions though)

Heh I won't ask you to debug random code for me.

Is this situation materially different from JS code that throws something other than an Error object? e.g. don't you also get an exception without a stack trace in that case?

You will not have a stack trace, correct, though many JS engines can helpfully show you the location of the throw as long as it was not caught. I've also never had to debug code which does this in practice, and I would consider such code to be "extremely bad".

Perhaps this is more about how implementations should present exceptions, which is outside the control of wasm, but I would like to push for better information in the part we do have say over, the JS bindings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants