Wasmtime GitHub notifications bot (May 02 2023 at 17:20): Wasmtime GitHub notifications bot (May 02 2023 at 17:20):alexcrichton commented on issue #6321:
Oh one thing I thought of this morning -- this means that the backtrace code is no longer guaranteed to walk the stack in-order of activations. I don't believe there's any issues with that, but it's worth being aware of. The reason for this is that while the activations are ordered when we walk each activation we walk its
old_*pointers which are the previous pointers for the limits.If you had A call B call A which trapped, then you'd get the first contiguous region in A but then when you walk over the
CallThreadStatethe first one points to the first A on the stack. The nextCallThreadStatewould... actually I think B would be dropped entirely?Hm ok so now as I write this out, I think it means that
Backtraceis no longer guaranteed to capture all frames on the stack, no in order. That's ok though since it's guaranteed to capture everything within one store's limits in order which is all we need.
Wasmtime GitHub notifications bot (May 02 2023 at 17:34):jameysharp commented on issue #6321:
I don't understand the issue you're raising, Alex, but my profiling work will produce misleading results if the subset of stack frames which are part of the user-selected modules are returned out of order. Should I be concerned about this?
Wasmtime GitHub notifications bot (May 02 2023 at 17:41):alexcrichton commented on issue #6321:
Sort of yes and sort of no. Within a single
Store<T>there's nothing to worry about, everything will always be in-order. What this means though is that if there are multiple stores on the stack then the frames will be out of order. Or more precisely, the originating store will have in-order frames and the other stores may or may not have frames interspersed in whatever order (depends on exact details).This is ok for
WasmBacktracesince it goes through a symbolication phase that discards anything it can't symbolicate, and it can only symbolicate modules registered in the store. In theory this discards any non-store frames, although as I'm typing this I'm now realizing that the same module can be instantiated in different stores so this isn't quite true.For the profiler just added, however, it doesn't do any filtering, so it does mean that frames will be out of order since non-store-local frames are not filtered out.
@fitzgen I'm actually going to bump this out of the queue now that I think on this more. I'm worried about the case where a module is instantiated in two stores and then the store are interleaved. All frames will symbolicate in either store but the stacks are going to be quite odd. I think we should actually explicitly update backtracing to take a
*mut VMRuntimeLimitsparameter and only trace activations for those limits?
Wasmtime GitHub notifications bot (May 02 2023 at 17:50):jameysharp commented on issue #6321:
The new profiler actually does filter to only frames from a specified set of modules, but your point still stands because it has the same problem that
WasmBacktracedoes, that the same module might be instantiated in multiple stores.
Wasmtime GitHub notifications bot (May 02 2023 at 22:44):github-actions[bot] commented on issue #6321:
Subscribe to Label Action
cc @fitzgen, @peterhuene
<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
- fitzgen: wasmtime:ref-types
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Last updated: Dec 23 2024 at 12:05 UTC