Closed Bug 1098258 Opened 6 years ago Closed 6 years ago
Install minidump stackwalk and define symbols path for Marionette unit tests
1.31 KB, patch
|Details | Diff | Splinter Review|
MozReview Request: Bug 1098258 - Make sure symbols_path and MINIDUMP_STACKWALK are set for desktop marionette, r=jgriffin
38 bytes, text/x-review-board-request
It appears that crash dumps are not being processed for Marionette unit tests due to the symbols path not being provided and the MINIDUMP_STACKWALK environment variable not being set. See an example crash in the following log: https://treeherder.mozilla.org/logviewer.html#?job_id=3812049&repo=mozilla-inbound
What's needed here? Is this simply a case of adding the following to the config dict in mozharness/configs/marionette/test_config.py: "download_symbols": "ondemand", "download_minidump_stackwalk": True, Is there a reason these are not already set? Why do we only set the symbols path for emulator and gaiatest? Needinfo'ing chmanchester and jgriffin based on their contributions to the Marionette mozharness components.
/r/585 - Bug 1098258 - Make sure symbols_path and MINIDUMP_STACKWALK are set for desktop marionette, r=jgriffin Pull down this commit: hg pull review -r 9b5adc0154ac26c96fa23ce76c6f721df39709ac
The answer to your question is probably "no good reason".
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
Here's the gecko patch. And here it is on Ash: https://treeherder.mozilla.org/ui/#/jobs?repo=ash&revision=71ed097fc3e4
Attachment #8522250 - Flags: review?(jgriffin)
Attachment #8522226 - Flags: review?(jgriffin) → review+
https://reviewboard.mozilla.org/r/583/#review245 Yeah, the current exclusion for desktop Marionette is confusing, and probably and acccident. Thanks for fixing.
Attachment #8522250 - Flags: review?(jgriffin) → review+
https://hg.mozilla.org/build/mozharness/rev/3a32e88478ff It's not safe to land the gecko patch until the mozharness one is merged to production.
Awesome, we have crash details! https://treeherder.mozilla.org/ui/logviewer.html#?job_id=66196&repo=ash
Oh, hmm. Does that mean if I land the gecko patch the same oranges will be exposed as were exposed by your patch? If that's the case, then I guess we need to look into getting a developer to fix it before I can land :/.. Once the mozharness patch is merged to production it should at least be trivial for them to push to try with the gecko patch and we can provide the instructions.
(In reply to Andrew Halberstadt [:ahal] from comment #9) > Oh, hmm. Does that mean if I land the gecko patch the same oranges will be > exposed as were exposed by your patch? If that's the case, then I guess we > need to look into getting a developer to fix it before I can land :/.. No, we see the crash but it still doesn't cause the test to fail without my patch.
The mozharness change was merged to production. https://hg.mozilla.org/integration/mozilla-inbound/rev/6a1a0a357f11
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.