I'm seeing situations like this:
We've hit an assertion but the logged call stack is of limited utility (without a lot of tedious manual intervention) due to lack of symbolication. We have the breakpad symbols for the build, but MozDescribeCodeAddress uses debughlp which groks pdb. If pdbs aren't around, we're not going to get much out of it.
I'm not sure what the best way forward is. Does breakpad have some kind of facility to act as a MS symbol server? Or do we need to add breakpad .sym parsing to MozDescribeCodeAddress?
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #0)
> I'm not sure what the best way forward is. Does breakpad have some kind of
> facility to act as a MS symbol server? Or do we need to add breakpad .sym
> parsing to MozDescribeCodeAddress?
(This also makes debugging in mozharness test environments more difficult, so I'd suggest that a symbol server option is probably more preferable than just modifying MozDescribeCodeAddress).
Our other harnesses just post-process assertion stacks using https://dxr.mozilla.org/mozilla-central/source/tools/rb/fix_stack_using_bpsyms.py, like:
We should just add that same code to the C++ unittest harness:
Created attachment 8709133 [details] [diff] [review]
Locally on mach and on try by looking at the stacks in the assertions on this try push:
Comment on attachment 8709133 [details] [diff] [review]
Review of attachment 8709133 [details] [diff] [review]:
Thanks for fixing this!
Backed out in https://hg.mozilla.org/integration/fx-team/rev/aeacd77c05b5 for android cpp test failures:
Bug 1238305: Modify cppunittests to look up breakpad symbols for logged stack traces; r=ted
I had to back this out for cpp test failures (this time on Windows debug) like https://public-artifacts.taskcluster.net/dsz6T2p6S-KvcVrDdNySaw/0/public/logs/live_backing.log