Hi Andrew, On 06/03/2020 01:27, Andrew Sutherland wrote: > Does this eliminate the need documented at > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks > to acquire a `minidump_stackwalk` binary and then expose it via > MINIDUMP_STACKWALK environment variable to get symbolicated backtraces > when local test runs crash? Or is that part of the future work to "use > `fix-stacks` on test outputs"?
the short answer is no. We use `minidump_stackwalk` to pull out the stack trace from a crash and print it, the stack-fixing scripts can't do that. However, if the frames printed out by `minidump_stackwalk` are not symbolicated (it can happen) then the stack-fixing scripts will try to symbolicate the un-symbolicated lines in the output. Generally speaking the stack-fixing scripts are needed because we often print stack traces from inside Gecko - by using MozStackWalk() for example - and those don't have symbols. So the stack-fixing scripts scan Gecko's output and when they find something that looks like an unsymbolicated entry in a stack-trace they replace it with the appropriate symbol. Now for the long answer: we're leveraging the Sentry crates to replace our current crash reporting machinery. Not only they're faster and better than what we have now but their functionality is far richer. So it will be possible - and possibly even desirable - to fold all of this functionality into a single tool that knows how to do both stack-walking and symbolication. For now we're just building 1-to-1 replacements of what we have because that's the path of least resistance to replace our aging tools and it yields very tangible perf and memory consumption improvements as Nicholas highlighted in his post. Gabriele _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
