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 CallThreadState the first one points to the first A on the stack. The next CallThreadState would... actually I think B would be dropped entirely?

Hm ok so now as I write this out, I think it means that Backtrace is 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.

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?

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 WasmBacktrace since 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 VMRuntimeLimits parameter and only trace activations for those limits?

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 WasmBacktrace does, that the same module might be instantiated in multiple stores.

Subscribe to Label Action

cc @fitzgen, @peterhuene