Open Bug 1286294 Opened 3 years ago Updated Last year
xpcshell invocation during startupcache precompile does not symbolicate crash stacks
I have a patch that causes a crash in the "B" job on tree herder, during ./mach package, but the resulting crash stack does not get symbolicated. This is Linux 64 debug: https://treeherder.mozilla.org/#/jobs?repo=try&revision=679316d054f7&selectedJob=23678007
Summary: Build step does not symbolicate steps → Build step does not symbolicate crash stacks
We run xpcshell to precompile the startupcache during packaging. The code that does that is here: https://dxr.mozilla.org/mozilla-central/rev/88bebcaca249aeaca9197382e89d35b02be8292e/toolkit/mozapps/installer/packager.py#60 We've already run `buildsymbols` by the time we run `package` (except for PGO builds...), so in this case we should be able to pipe the output through a stack fixer function like we do in our test harnesses: https://dxr.mozilla.org/mozilla-central/rev/88bebcaca249aeaca9197382e89d35b02be8292e/testing/xpcshell/runxpcshelltests.py#1226 It looks like we could just pass `os.path.join(self.tooldir, 'bin')` for `utility_path` in this case, and `os.path.join(self.tooldir, 'crashreporter-symbols')` for `symbolsPath`. We would need to change that `subprocess.call` invocation to pipe the output somehow (and maybe pipe stderr to stdout) and feed each line through the stack fixer function before printing it. We could switch it to use mozprocess which might make that all simpler.
Summary: Build step does not symbolicate crash stacks → xpcshell invocation during startupcache precompile does not symbolicate crash stacks
You need to log in before you can comment on or make changes to this bug.