1432886 - windows debug crashtests panicking in rust code don't provide useful backtraces

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 2

[(not currently active) Ted Mielczarek]

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.