See https://treeherder.mozilla.org/logviewer.html#?job_id=158183123&repo=mozilla-inbound&lineNumber=1733 for example. There's a panic but the backtrace is not particularly useful.

FWIW it seems like we are generating all the symbols properly in the build job, and I was able to hand-symbolicate a bunch of the addresses in the backtrace. I don't know the mechanics of how it's supposed to happen in automation but I suspect there's just some glue or env var that's not hooked up properly. Maybe this bug belongs under testing automation.

I think this should be simple to fix. If you look further down in the log, we generate a minidump when the process crashes, and we produce a symbolicated stack from it, so the symbols are fine: https://treeherder.mozilla.org/logviewer.html#?job_id=158183123&repo=mozilla-inbound&lineNumber=64251 Process output from our test harnesses is piped through a "stack fixer" function which is provided by importing one of the `fix_*_stack.py` scripts in tools/rb, usually by calling `mozrunner.get_stack_fixer_function`: https://dxr.mozilla.org/mozilla-central/rev/e22e2c9eb81686e958a9448ea3d1e8cd766743e2/testing/mozbase/mozrunner/mozrunner/utils.py#241 https://dxr.mozilla.org/mozilla-central/source/tools/rb Those scripts use a regex to match stack frames output from NS_FormatCodeAddress: https://dxr.mozilla.org/mozilla-central/rev/e22e2c9eb81686e958a9448ea3d1e8cd766743e2/tools/rb/fix_stack_using_bpsyms.py#145 (unfortunately the regex is duplicated across all three scripts). Making that regex match the Rust backtrace output should fix this.