Stream: wasi

Topic: new backtrace API?

Andrew Brown (Oct 19 2023 at 00:08):

I was troubleshooting a WebAssembly program today and found the following extremely useful: an API for dumping the current WebAssembly backtrace. I tried using unreachable to do this (it will exit the program and in Wasmtime, e.g., will print the WebAssembly backtrace) but I was dealing with a multi-threaded program in which I needed a backtrace from various threads — if I trapped the program with unreachable I would not be able to retrieve all the backtraces I needed. I created a single imported function to log the current backtrace and called it in all the places I needed it, much like one would do with debugger in the browser.

As I talked to @fitzgen (he/him) about this, he suggested it could be a WASI API: until full debugging support is available in all the engines, etc. (which may take a while), this API could be used for troubleshooting. It would involve a re-compile, much like "printf" debugging, but it has the significant advantage that one could see the entire backtrace, which is quite important when programs get more complex.

I used log messages to get the information I needed, but as a WASI API I think it would make more sense as: wasi::capture_backtrace() -> list<(module-name, function-name)>, where both *-names are strings. Obviously this could be made more or less complex. What I'm trying to get at here is: is anyone else interested in standardizing this kind of API?

David Lloyd (Oct 19 2023 at 13:55):

it would be neat if it could also include some positional information like the call instruction byte offset in the function (if known) for each frame... this would make it adequate for the purposes of generating stack traces for Java exceptions

Andrew Brown (Oct 19 2023 at 16:18):

yeah, reflecting on this: we really want to return a list<frame> where frame contains module name/index, function name/index, potentially that bytecode offset, etc.

Zalim Bashorov (Kotlin, JetBrains) (Oct 19 2023 at 18:05):

It would be useful to have such a capability both outside and inside browsers

Zalim Bashorov (Kotlin, JetBrains) (Oct 19 2023 at 18:15):

I, basically, thought about having two primitives

• get_stacktrace -- which returns an array of id's
• get_function_name -- which returns an array of bytes with string encoded utf8

Zalim Bashorov (Kotlin, JetBrains) (Oct 19 2023 at 18:15):

But yeah, for completeness, we need a module name and offset.

Zalim Bashorov (Kotlin, JetBrains) (Oct 19 2023 at 18:15):

An ability to get function names by id, could be useful in some other cases, e.g. help us avoid duplicating this information in binaries for limited(!) reflection capabilities.

fitzgen (he/him) (Oct 19 2023 at 20:52):

ideally it would have all the same info that is in a core dumps stack trace: https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md#threads-and-stack-frames

Last updated: Dec 23 2024 at 12:05 UTC